那么即使马丁基本上回答了这个具有非常的猜测,我进入这个作为答案因为它太长了评论进入。
这里是证据...
•事实上,10.7时自动保存和版本推出,所以这就是为什么你没有看到UF_TRACKED在stat.h 10.6。
•我在运行Mac OS X 10.7的Mac上试过我的实验,它的行为与10.8中的相同。
•有是的模式:一些应用程序,它检查后数似乎是那些已经采用了自动保存和版本创建的文档文件,是在1 UF_TRACKED = 0×40的人。
•另一个实验。我改名为Mac OS X中的修订守护可执行文件,
/System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond
然后重新启动Mac和监控的UF_TRACKED状态Dropbox中有0x40的文档文件。然后,我在另一台Mac上更改了该文件,以便Dropbox将其禁用到版本的守护程序,并将其推送到此Mac。结果:文件的UF_TRACKED状态从0x40更改为0x00,但这次确实是而不是在2秒后变回0x40。
•它做变化为0x40 30秒后,当我恢复了修订守护它原来的名字,并重新启动。 (显然修订是通过启动KeepAlive属性启动的。)
==================
因此证据是压倒性的,马丁的猜测是正确的。它是Apple的修订后台程序而不是Dropbox,它将UF_TRACKED设置为0x40。这一点的意义在于它的文档修订版正在被Lion Auto Save和Versions追踪。
啊,头文件!因此,在这种情况下,“用户”看起来就是unix文件所有者(如所有者,组,所有人)。这个UF_TRACKED是超出其他stat状态的8个标志位之一,或者限制文件可能/应该被修改。我想知道这些规则是否有任何强制执行机制,或者它们只是关心看待它们的计划的咨询。我将不得不做一些实验。 – 2013-05-11 15:52:29
@JerryKrinock:这些标志绝对不仅仅是咨询。例如,如果您执行“chflags uappend myfile”,则“ls> myfile”(覆盖)将失败,但“ls >> myfile”(append)有效,因此标记“仅附加”由文件系统强制执行。 – 2013-05-11 15:55:49
@JerryKrinock:我能找到的唯一一个对'UF_TRACKED'的引用是http://stackoverflow.com/questions/10607877/uf-tracked-file-flag-from-stat-h。我*认为*这与OS X的“自动保存和版本”功能相关,但这只是一个猜测。 – 2013-05-11 15:57:29