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 上发现了这种奇怪的行为：
大多数应用程序都无法保留它们的首选项——尤其是 Mail.app，它发出错误消息警告，表明它无法写入~/Library/Preferences.

深入挖掘，我发现——不知何故——大多数 plist 都有一个带有指令的 ACL group:everyone deny delete；放弃这条规则挽救了一天。

我怀疑NSArray|NSDictionary|NSWhatHaveYou'writeToFile:atomically:应对这种行为负责*，而且——果然——我写的测试工具只有在NO作为第二个参数传递时才会成功，如果文件存在并且有这样的 ACL 就位......

（*“负责”我只指非写作部分；ACL 情况完全是另外一回事）

所以我想知道：

这是错误还是功能？

虽然 - 从技术上讲 - 此方法写入文件并在完成后重命名它，但从用户的角度来看，它并没有删除任何内容......

如果是错误：
应该针对 NSArray 和朋友提交还是针对 ACL 的实现提交？

任何想法都非常感谢！

干杯

丹尼尔

4

1 回答 1

0

在对HFS 源代码进行了一些挖掘之后，我得出的结论是，rename在 Mac OS 中没有文件系统原生函数之类的东西。

相反，它被实现为（伪代码）

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

所以这种行为是可以预料的:-(

也就是说，我对文件系统或低级编程的了解还不够，无法决定创建一个本地程序是否rename值得为实现它而烦恼。

我强烈认为这样做是正确的，但是...

编辑

正如jfortman 指出的那样，通过使用以下序列，原子重命名实际上是可能的并且非常简单：

  1. 写入临时文件
  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 回答