「rsync」コマンドを使用するときに「--modify-window = 1」を使用するのはなぜですか？

Question 1

「modify_window」の仕組みに関する混乱を避けるために、どちらの方向でも確認してください。（この内容をソースコードで読むには、util.c :: cmp_time（）を確認してください。）

これは意味する、

A が B より最新の場合は、A が B+update_window より最新であることを確認します。
B が A よりも最新の場合は、B が A+ 修正ウィンドウよりも最新であることを確認します。

元のAの時間は123ですが、バックアップファイルシステムが不都合であるため、コピーBの時間は122（AをBよりも最新）または時間124（BをAよりも最近）で終わります。

編集ウィンドウ= 1の場合はどうなりますか？

A（123）がB（122）よりも最新の場合は、A（123）がまだB（122 + 1 = 123）よりも最新であることを確認してください。
B（124）がA（123）よりも最新の場合は、B（124）がまだA（123 + 1 = 124）よりも最新であることを確認してください。

どちらの場合も、結果は同じであるため、変更ウィンドウ= 1の場合は、どちらの方向でも1秒ずつオフセットするのに十分です。

rsyncのマニュアルページによると、これはFAT32には十分です。

あなたが引用した文書によると（122を124に置き換えること、一体何ですか）これは十分ではありません。

したがって、陪審員団はまだこれについて判断していません。

実験を通して、LinuxでNTFS（-3g）とFAT32を使用すると、修正_window = 1が正しく動作するようです。

私のテスト設定は次のとおりです。

truncate -s 100M ntfs.img fat32.img
mkfs.ntfs -F ntfs.img
mkfs.vfat -F 32 fat32.img
mount -o loop ntfs.img /tmp/ntfs/
mount -o loop fat32.img /tmp/fat32/

したがって、1億NTFS/FAT32ファイルシステムです。

さまざまなタイムスタンプを含む数千のファイルを作成します。

cd /tmp/ntfs

for f in {000..999}
do
    sleep 0.0$RANDOM # widens the timestamp range
    touch "$f"
done

たとえば、

# stat --format=%n:%y 111 222 333
111:2018-08-10 20:19:10.011984300 +0200
222:2018-08-10 20:19:13.553878700 +0200
333:2018-08-10 20:19:17.765753000 +0200

あなたに20:19:10.011よると2018-08-10 20:19:12.000。

それでは、何が起こるのか見てみましょう。まず、これらのファイルをすべてFAT32にコピーします。

# rsync -a /tmp/ntfs/ /tmp/fat32/

その後、アンインストールして再インストールするまで、タイムスタンプが実際に正しいことを確認しました。

# umount /tmp/fat32
# mount -o loop fat32.img /tmp/fat32

比較する:

# stat --format=%n:%y /tmp/{ntfs,fat32}/{111,222,333}
/tmp/ntfs/  111:2018-08-10 20:19:10.011984300 +0200
/tmp/fat32/ 111:2018-08-10 20:19:10.000000000 +0200
/tmp/ntfs/  222:2018-08-10 20:19:13.553878700 +0200
/tmp/fat32/ 222:2018-08-10 20:19:12.000000000 +0200
/tmp/ntfs/  333:2018-08-10 20:19:17.765753000 +0200
/tmp/fat32/ 333:2018-08-10 20:19:16.000000000 +0200

だからこれは私にとって衝撃的なようです。 Windowsが同じ方法でこれを行うかどうかはわかりませんが、Linuxとrsyncを使用したときに起こります。

再コピー時に rsync が実行するアクション:

# rsync -av --dry-run /tmp/ntfs/ /tmp/fat32
sending incremental file list
./
000
001
002
035
036
...
963
964
997
998
999

したがって、リストにはいくつかのスペースがありますが、全体的にかなりの数のファイルを再コピーします。

使用すると、--modify-window=1リストは空です。

# rsync -av --dry-run --modify-window=1 /tmp/ntfs/ /tmp/fat32/
sending incremental file list
./

したがって、少なくともLinuxの場合、マニュアルページは正確です。オフセットは決して1より大きくないようです。 (まあ、1にスコアを加えた値ですが、それも無視されます.)

それでは、--modify-time=2それを使うべきですか？これが実際に可能なシナリオであることを実験的に証明できるまでです。それにもかかわらず、話すのは難しいです。まず、これはひどいハッキングです。時間枠が大きいほど、実際の修正を見逃す可能性が高くなります。

FAT32タイムスタンプの丸め方法とは無関係な変更も--modify-time=1無視されました。双方向であるため、FAT32はフロアのみ実行でき、rsyncはFAT32にコピーするときにそれを無視し（ターゲットファイルは古いファイルのみ可能）、その逆の場合も同様です。 FAT32からコピーする場合も同様です（対象ファイルは最新のファイルのみ可）。

この問題を処理するのにこれ以上のオプションはないようです。

また、カーネルのソースコードでこの動作を追跡してみましたが、残念ながらコメント（linux / fs / fat / misc.c）では多くの情報を提供できませんでした。

/*
 * The epoch of FAT timestamp is 1980.
 *     :  bits :     value
 * date:  0 -  4: day   (1 -  31)
 * date:  5 -  8: month (1 -  12)
 * date:  9 - 15: year  (0 - 127) from 1980
 * time:  0 -  4: sec   (0 -  29) 2sec counts
 * time:  5 - 10: min   (0 -  59)
 * time: 11 - 15: hour  (0 -  23)
 */

したがって、これに基づいて、FATタイムスタンプは5ビットを使用して秒を表示するため、32の可能な状態しか取得できず、そのうち30が使用されます。変換は簡単なビットシフトで行われます。

fs/fat/misc.c::fat_time_unix2fat()から

    /* 0~59 -> 0~29(2sec counts) */
    tm.tm_sec >>= 1;

つまり、0は0、1は0、2は1、3は1、4は2などです。

fs/fat/misc.c::fat_time_fat2unix() から

    second =  (time & 0x1f) << 1;

上記とは異なり、0x1f0〜29秒を表すFAT時間のビット0〜4のみを取得するビットマスクです。

これが元のものと異なる場合、コメントには何も表示されません。

Raymond Chenは、Windowsがラウンドタイムになぜそのような問題に遭遇するのかについての興味深い記事を投稿しました。https://blogs.msdn.microsoft.com/oldnewthing/20140903-00/?p=83

いいですね。しかし、タイムスタンプが常に最も近い2秒間隔で増加するのはなぜですか？最寄りの2秒間隔で丸めたらどうでしょうか？これにより、タイムスタンプが最大1秒ずつ変更されます。

最も近い間隔に丸めると、ファイルが時間を逆にして問題が発生する可能性があるためです。（因果関係が問題になる可能性があります。）

これによれば、Windowsツールには、「ソースファイルがターゲットファイルより最新の場合にのみコピー」というフラグがxcopyあります。/D基本的に何rsync --updateをするcp --updateのか。

ファイルが過去1秒前に作成されたように見えるように時間を丸めると（Linuxのように）、コマンドが実行されるたびにファイルがコピーされます。時間を四捨五入すると、この問題は解決されます。

OTOH Windowsソリューションは、これらのファイルを再コピーすると同じ問題を引き起こす可能性があります。実際より最新のファイルをコピーするため、ロールアップが2回発生しないように注意してください。

何をしても常に間違ったことであり、タイムスタンプを正しく保存できないファイルシステムは単に面倒です。

Answer