私は定期的にrsyncを使っていくつかのファイルを外付けハードドライブにバックアップします。時々、ビット破損を検出するために、チェックサムモードでrsyncを使用してディスク上のファイルの整合性をチェックします。
今日まで、すべてが良いです。私のコマンドは次のとおりです。
rsync -nrvci source dest
-n練習の実行、
-r再帰、-v詳細情報の表示、チェックサム-cモード、および-iファイルが変更された理由を確認するために使用されます。
今回は、一部のファイルに異なるチェックサムがあることが報告されており、項目別リストには、すべての問題ファイルに対して次の文字列が表示されます。>fc.T......
マニュアルページによると、これはファイルが転送中で、ターゲットとチェックサムが異なるファイルである>ため、コピー時にタイムスタンプが変更されることを示しています。私の仮定が間違っている可能性があります。fcT
とにかく実行するとmd5sum source/file dest/file一致します。 rsyncがmd5メソッドを使用するようにコマンドに追加しました--checksum-choice=md5が、役に立たないがまだチェックサムが異なることを報告します。
rsyncはどうなりましたか？実際にはそうではありませんが、なぜこれらのファイルが異なるように見えますか？
答え1
Linux Ubuntuサーバーでファイルを同期するためにMacbookでrsyncを実行するのと同じ問題が発生しました。 2つのディレクトリを同期するには（常にrsync -vrc）、常に同じファイルを除いて変更されていないすべてのファイルを無視します。
-i使用量も報告されます>fc.T......（または提供されている>fc........場合--times）。md5sumソースファイルとターゲットファイルは同じ結果を提供します。- 別のターゲットディレクトリを使用 - >同じ結果
- ファイル名の変更 - >同じ結果
- rsyncを実行しているユーザーがソースファイルを書き込むことができるようにします - >同じ結果
touch-ing ソースファイル --> 同じ結果
これをすべて試した後（そしてこれがソースファイルストアに何らかの問題ではないと確信していました。mds5um常に同じチェックサムを提供します）、私はそれ自体が何か問題であると予想しましたrsync。
最新のrsyncバージョンをインストールした後（Stock macos Ventura 13.2.1にはまだバージョンがあり、rsync version 2.6.9 protocol version 29homebrewを使用してインストールされているrsync version 3.2.7 protocol version 31）問題がなくなりました。
答え2
rsync または Veracrypt には 1 回限りの問題があるようです。メディアを取り出し、再インストールした後、問題は消えました。だから、「off and on again」が再び流行しています。
編集：1ヶ月後にこの問題が再発生しました。今回も、通常のユーザーとしてrsyncを実行するのではなく、sudoを使用して問題を解決できました。