Mac OS X でユーザーの Dropbox 内のファイルを更新するために Dropbox がビジーであることを検出しようとしています。ファイルに対して stat(1) または stat(2) を実行すると、ファイル (st_flags) のユーザー定義フラグが通常0x40 ですが、Dropbox がファイルを更新している間、数秒間 0x00 に変わります。
デスクトップや他のフォルダを調べてみると、ファイルの約 95% にはフラグ値 0x00 があり、約 5% には値 0x40 があることがわかります。したがって、これは単なる Dropbox 実装の詳細ではない可能性があります。どのファイルに 0x40 フラグがあるかを予測するためのパターンを識別できません。これらの値の意味を知っている人はいますか? それらを定義している「ユーザー」は誰ですか?
マーティンは基本的に非常に知識に基づいた推測でこれに答えましたが、コメントとして入力するには長すぎるため、これを答えとして入力します。
これが証拠です…</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 を再起動し、0x40 を持つ Dropbox 内のドキュメント ファイルの UF_TRACKED 状態を監視しました。次に、別の Mac でファイルを変更して、Dropbox がリビジョン デーモンを無効にしてこの Mac にファイルをプッシュするようにしました。結果: ファイルの UF_TRACKED 状態が 0x40 から 0x00 に変更されましたが、今回は2 秒後に 0x40 に戻りませんでした。
•リビジョン デーモンを元の名前に復元し、再起動した後、30 秒後に 0x40 に変わりました。(明らかに reved は、 KeepAlive属性を持つ launchd によって開始されます。)
==================
したがって、Martin の推測が正しいという証拠は圧倒的です。UF_TRACKED を 0x40 に設定しているのは Dropbox ではなく、Apple のリビジョン デーモンです。このビットの意味は、ドキュメントのリビジョンが Lion Auto Save and Versions によって追跡されていることです。
フラグは、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」のマンページにはありません。
残念ながら、「追跡」とは正確に何を意味するのかはわかりませんが、おそらくこれは、より多くの情報を見つけるのに役立つでしょう.