0

ACL ルールが の書き込み可能なファイルがある場合deny delete、どの[plistableObject writeFoFile:undeletableFile atomically:YES]呼び出しでも が返されますがNO、アトミックでない書き込みは成功します。

アトミック書き込みとは、一時ファイルが書き込まれ、正常に書き込まれた場合は最終的に名前が変更されることを意味します。ただし、この特定の意味は奇妙に感じます。
それで、これが原因なのだろうか...

  1. HFS+ には直接の「名前変更」がありません。
  2. -[NS(Array|Dictionary|Data|String) writeToFile:atomically:]またはの実装における欠陥
  3. Mac OS X での ACL の実装の欠陥?

前もって感謝します

ダニエル

元の質問:
先日、バックアップから復元した Mac でこの奇妙な動作を発見しました:
ほとんどのアプリケーションは設定を保持できませんでした。~/Library/Preferences.

さらに掘り下げてみると、どういうわけか、ほとんどの plist にはディレクティブgroup:everyone deny deleteが配置された ACL があることがわかりました。このルールを捨てることで、その日は救われました。

私はNSArray|NSDictionary|NSWhatHaveYou'swriteToFile:atomically:がこの動作の原因であると考えました*。確かに、私が作成したテストツールはNO、ファイルが存在し、そのような ACL が設定されている場合に、2 番目の引数として渡された場合にのみ成功します...

(* ここで、「責任がある」とは、書いていない部分のみを意味します。ACL の状況はまったく別のものでした)

だから私は疑問に思います：

これはバグですか、それとも機能ですか?

技術的には、このメソッドはファイルを書き込み、完了時に名前を変更しますが、ユーザーの観点からは何も削除していません...

バグの場合
: NSArray や友人に対して、または ACL の実装に対して提出する必要がありますか?

どんな考えでも大歓迎です！

乾杯

ダニエル

4

1 に答える 1

0

HFSソースを掘り下げた結果rename、MacOSにはファイルシステムネイティブ関数のようなものはないという結論に達しました。

代わりに、（擬似コード）として実装されます

link!
successful:
   return 0
// otherwise
unlink!
successful:
  link!
  return error_code
// otherwise
return error_code

したがって、この動作は予想されます:-(

renameとは言うものの、ネイティブの作成がそれを実装する手間をかける価値があるかどうかを判断するためのファイルシステムまたは低水準プログラミングについては十分に知りません。

そうするのが正しいと強く感じますが...

編集

jfortmanが指摘したように、アトミックな名前変更は実際には可能であり、次のシーケンスを使用することで非常に簡単です。

  1. tempfileに書き込む
  2. exchangedata( path_to_tempfile, path_to_destination_file, options )（ちなみに、マンページには、この関数はDarwin 1.3.1 / Mac OS X 10.0以降に使用されていると記載されています...）
  3. 一時ファイルを削除する
于 2011-01-09T15:37:28.227 に答える