fstabで拡張ファイル属性が有効になっているext4に、DebianとUbuntuという2台のコンピュータがあります。 getfattrとsetfattrは両方のシステムにローカルにインストールされ、完全に実行されます。ただし、unison（バージョン2.40.102）はデフォルトで拡張ファイルのプロパティを同期しません。
Googleで見つけました。これ拡張属性同期を有効にする必要があるプロファイル設定を含むブログ投稿。だからプロフィールを変更しましたが、今は次のようになります。
root=/path/to/dir
root=ssh://[email protected]//path/to/dir2
auto=true
batch=true
perms=0
rsync=true
maxthreads=1
retry=3
confirmbigdeletes=false
copythreshold=0
copyprog = rsync -aX --rsh='ssh -p 22' --inplace --compress
copyprogrest = rsync -aX --rsh='ssh -p 22' --partial --inplace --compress
copyquoterem = true
copymax = 1
このプロファイルは新しいファイルの拡張属性を同期しますが、すでに同期されているファイルの拡張属性を変更して一貫して実行すると、次の結果が表示されます。
Nothing to do: replicas have not changed since last sync.
他のすべては完全に同期されますが、一貫性は拡張属性の変更を認識しません。また、ファイルをより詳細にスキャンできるようにしたいので、fastcheckを無効にしてみました。一方向にrsyncを試してみましたが、完璧に動作しました。ただし、双方向同期が必要なため、一貫性のみを維持できます。
公式マニュアルをずっと見ましたが、通り過ぎる拡張ファイル属性だけが言及されています。だから私の質問はこんな感じです。これを一貫して実行できますか？ここで簡単なものを見逃していますか？または、これを達成できる他のオープンソースツールはありますか？ （私はbsyncとbitpocketについて知っていますが、予備テストでは拡張ファイルプロパティの変更も見つかりませんでした。）
答え1
後で私と同じ問題が発生した場合に備えて、unisonは拡張ファイルのプロパティでは機能しません。これを解決する1つの方法はcopyprog + copythreshold = 0ハッキング（元の質問の設定ファイルを参照）ですが、xattrの変更を継続的に認識しないという問題は解決されません。コメントの1つで述べたように、ファイルの変更時間を変更しても、変更されたxattrは一貫して同期されません。それだけでなく削除次にファイルの内容が変更されたとき。
双方向同期に拡張ファイル属性を使用できる唯一の方法は、次の方法を使用することです。同期、rsyncパラメータに-Xフラグを追加し、ファイルの変更時間を変更して変更します。
これは、ファイルの変更時間の変更、Windowsのサポートなし、Python 3の依存関係、最後のコミットが昨年など、理想的なソリューションとは離れていますが、私が見つけたこれを行うことができる唯一のソフトウェアです。
答え2
おそらくマニュアルで見た内容でしょう。2.27以降の変更それは言う
ファイルが変更されていなくても、Unisonがファイル転送に失敗し、「同期中にターゲットが更新されました」という役に立たないメッセージが表示されることがあります。手続きの変更によるものかもしれません。ファイル拡張属性修正時間を変更せずに。最善の解決策が何であるかは不明です。ユニソンのせいではありませんが、ユニソンの行動を恥ずかしくさせます。
そのため、Unisonは主にファイルを変更する時点にのみ焦点を当て、それ以外には何もないようです。私が試した解決策は、拡張属性が変更されるとすぐにファイルの変更時間を更新することでした。これにより、Unisonは変更を認識し、ファイルを同期します。ただし、これが可能かどうかは、拡張属性を変更する方法によって異なります。
inotifytoolsファイル拡張子のプロパティの変化を検出するために何かを使用することが可能だと思います。inotifytoosUnisonが同期するすべてのファイルを監視するスクリプトを作成し、変更が検出されtouchたらファイルを監視できます。