私はrsyncしばらくAndroidを使用してLinuxシステムのリモートNTFSファイルシステムに携帯電話をバックアップしてきました。
最近、NTFSファイルシステムを含むHDDが失敗し始めました（または「I / Oエラー」が発生しました）。そのため、すべてのファイルを新しいHDDと新しいNTFSファイルシステムにコピーする機会がありました。この場合、Windows用の「FastCopy v2.11」ツールを使用しました。
私の問題は、rsync "テストの実行"を実行すると、すでにリモートのrsyncフォルダにあるファイルを再コピーしようとしていることがわかります。たとえば、「-iv」を使用して実行すると、次のような出力が表示されます。
<f..t...... extSdCard/foo/bar
私が理解したところ、これは、rsyncがタイムスタンプの違いのためにこのファイルをリモートrsyncにコピーしようとしていることを意味します。
不思議なことに、Android用の「Astro」を使用してローカルファイルのプロパティを見ると、ファイルのサイズ、変更時間、MD5チェックサムがリモートファイル（ls -l変更時間を確認するために使用されます）とまったく同じであることがわかります。
最近、古いNTFSファイルシステムからリモートrsyncファイルをコピーした場合、リモートファイルのctimeは異なります（使用済みls -lc）。
リモートctimeを見ていますかrsync？それでは、これを使用またはrsync修正する方法はありますかntfs-3g？
答え1
デフォルトでは、rsyncはファイル比較のためにmtime / ctimeとサイズに依存しますが、このフラグを使用するとそれを-c無視し、コンテンツチェックサムを使用します。
問題は、この方法がはるかに遅くなる可能性があることです（モバイルデバイスでこれらのチェックサムを計算するのは非常に高価です）。これからは常にこのように実行する必要があるので、チェックサムなしで動作するようにしておくことが合理的かもしれません。一度実行し、デフォルトで使用されている mtime/ctime/size 比較方法に基づいてすべてを再度コピーします。しかし、少なくとも次回はチェックサムの計算に時間を費やすことはありません。
答え2
ちょうど速い実験を行った。 rsyncはmtimeを比較し、ctimeを無視します（少なくともMacでは）。残念ながら、Windowsファイルシステムにはctimeのみがあり、atimeとmtimeのctimeも返します。
これは、rsyncがコピーする必要がないWindowsファイルシステムからファイルをコピーするのに非常に攻撃的な理由です。 Unixファイルのmtimeは、Windowsファイルの「ctime」と比較されます。