AFAIK，OS X是BSD派生，没有实际的强制文件锁定。如果是这样，即使我正在编写文件，似乎也无法阻止从其他程序写入访问权限。
如何在这样的环境中保证文件的完整性？我的程序退出后我并不关心诚信，因为现在是用户的责任。但至少，我认为我的程序运行时需要某种保证。
如果没有强制锁定，其他程序如何保证文件内容的完整性？尤其是数据库程序如果有共同的技巧或推荐的做法，请告诉我。
更新
我正在为非工程用户寻找GUI应用程序的数据层。目前，我的计划有这种情况。
数据太大，无法适应RAM。甚至很难被临时复制。所以它不能以原子方式读/写，应该在程序运行时直接从磁盘使用。
非工程人员使用的长期专业GUI内容编辑器应用程序。虽然用户不是工程师，但他们仍然可以使用Finder或其他程序同时访问该文件。因此，用户可以意外删除或写入当前使用的文件。问题是用户不了解实际发生的情况，并期望程序处理文件完整性，至少程序正在运行。
我认为在当前情况下保证文件完整性的唯一方法是，
因为OS X缺少系统范围的强制锁定，所以现在我不知道该怎么做。但我仍然认为有一种方法可以存档这种文件完整性，这是我不知道的。我想知道其他人是如何处理的。
这个问题与我的编程错误无关。那是另一个问题。目前的问题是保护来自不遵守咨询文件锁定的其他程序的数据。而且，用户通常是root用户，并且程序是以相同的用户运行的，因此琐碎的Unix文件权限没有用。
答案 0 :(得分：4)
您必须查看您尝试通过强制锁定实际解决的问题。
强制锁定无法保证文件内容的完整性;除非你保持文件锁定24/7;文件完整性仍将取决于观察文件格式/访问约定的所有进程（并且由于硬盘驱动器错误等原因仍然可能失败）。
强制锁定可以保护您免受编程错误的影响（出于意外，不是出于恶意），无法遵守正确的锁定协议。同时，这种保护只是部分保护，因为无法获得锁定（强制或非强制）仍然可能导致文件损坏。强制锁定还可以减少可能的并发性。简而言之，强制锁定比针对软件缺陷的建议锁定提供了更多保护，但保护并不完整。
意外损坏问题的一个解决方案是使用经过积极测试的库来保护数据完整性。一个这样的库（还有其他库）是SQlite（另请参阅here和here以获取更多信息）。在OS X上，Core Data提供了一个基于SQLite的抽象层作为数据存储。显然，这种方法应该通过复制/备份来补充，这样您就可以防止数据损坏的其他原因导致存储层无法帮助您（媒体故障，意外删除）。
通过限制对数据库的文件访问并仅允许通过网关（例如套接字或消息库）进行访问，可以获得额外的保护。然后，您将只运行一个进程，只获取一个锁（并且永远不会释放它）。这个设置很容易测试;锁只是为了防止有多个网关进程实例在运行。
答案 1 :(得分：3)
一个简单的解决方案是简单地将文件隐藏起来，直到您的程序使用它为止。
隐藏文件有多种方法。这取决于您是要修改以前对用户可见的现有文件还是创建新文件。即使修改现有文件，最好创建一个隐藏的工作副本，然后将其内容与用户可见的文件进行原子交换。
隐藏文件的一种方法是在用户通常正常可见的位置创建文件。 （也就是说，文件不一定完全不可能被用户触及，只是为了让他们不会偶然发现它。）你可以使用-[NSFileManager URLForDirectory:inDomain:appropriateForURL:create:error:]获取这样的位置并传递{ {1}}和NSItemReplacementDirectory表示前两个参数。有关如何将文件原子移动到其文件位置的信息，请参阅NSUserDomainMask方法。
您可以使用各种API设置要隐藏的文件。您可以将-replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:与密钥-[NSURL setResourceValue:forKey:error:]一起使用。您可以使用NSURLIsHiddenKey系统调用来设置chflags()。旧的Unix备用数据库使用以句点（'。'）开头的文件名。
答案 2 :(得分：1)
以下是有关此主题的一些详细信息： https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileCoordinators/FileCoordinators.html
现在我认为OSX的基本政策是这样的。