7

我试图检测 Dropbox 何时忙于更新 Mac OS X 中用户 Dropbox 中的文件。通过在文件上运行 stat(1) 或 stat(2)，我看到用户定义的文件标志(st_flags) 通常是0x40，但当 Dropbox 更新文件时，它们会在几秒钟内更改为 0x00。

查看我的桌面和其他文件夹，我发现大约 95% 的文件的标志值为 0x00，但大约 5% 的值为 0x40。所以它可能不仅仅是 Dropbox 的实现细节。我无法辨别任何模式来预测哪些文件具有 0x40 标志。有谁知道这些值是什么意思？谁是定义它们的“用户”？

4

2 回答 2

11

好吧，尽管 Martin 基本上以非常有根据的猜测回答了这个问题，但我还是将其作为答案输入，因为作为评论输入的时间太长。

这是证据……</p>

• 事实上，10.7 是引入自动保存和版本的时候，所以这就是为什么您在 10.6 的 stat.h 中看不到 UF_TRACKED。

• 我在运行 Mac OS X 10.7 的 Mac 上尝试了我的实验，它的行为与 10.8 中的相同。

• 有一种模式：一些应用程序创建的文档文件，经过检查，其中一些似乎采用了自动保存和版本，是那些具有 UF_TRACKED = 0x40 的文件。

• 另一个实验。我重命名了Mac OS X 中的修订守护进程可执行文件，

/System/Library/PrivateFrameworks/GenerationalStorage.framework/Versions/A/Support/revisiond

然后重新启动 Mac，并监视 Dropbox 中具有 0x40 的文档文件的 UF_TRACKED 状态。然后我在另一台 Mac 上更改了文件，这样 Dropbox 就会在禁用修订守护程序的情况下将其推送到这台 Mac。结果：文件的 UF_TRACKED 状态从 0x40 变为 0x00，但这次在 2 秒后并没有变回 0x40。

•在我将修订守护进程恢复为其原始名称并重新启动后，它确实在 30 秒后更改为 0x40。（显然修订是由带有KeepAlive属性的 launchd 启动的。）

===================

因此，有大量证据表明马丁的猜测是正确的。将 UF_TRACKED 设置为 0x40的是 Apple 的修订守护进程，而不是 Dropbox。该位的含义是 Lion Auto Save 和 Versions 正在跟踪其文档修订。

于 2013-05-12T20:24:52.137 回答
8

可以使用chflags命令行工具或chflags()系统调用设置标志（参见man 2 chflags）。这些值可以在“/usr/include/sys/stat.h”中找到。

UF_TRACKED似乎有点特别。它记录在“sys/stat.h”中

#define UF_TRACKED    0x00000040 /* file renames and deletes are tracked */

但不在“chflags”手册页中。

不幸的是，我无法告诉您“跟踪”的确切含义，但也许这已经有助于找到更多信息。

于 2013-05-11T15:33:33.253 回答