Apenas para evitar qualquer confusão sobre como o modify_window funciona, ele é verificado em qualquer direção. (Se você quiser ler isto no código-fonte, verifique util.c :: cmp_time ().)
Isso significa que
- se A for mais recente que B, verificará se A ainda é mais recente que B + modify_window.
- se B for mais recente que A, verifica se B ainda é mais recente que A + modify_window.
Então, digamos que o original A tenha o tempo 123, mas seu sistema de arquivos de backup é ruim, então a cópia B termina com o tempo 122 (tornando A mais recente que B) ou o tempo 124 (tornando B mais recente que A).
O que acontece com modify_window = 1?
- Se A (123) é mais recente que B (122), verifica se A (123) ainda é mais recente que B (122 + 1 = 123).
- Se B (124) for mais recente que A (123), ele verifica se B (124) ainda é mais novo que A (123 + 1 = 124).
Em ambos os casos, ele é idêntico, então modify_window = 1 é suficiente para o tempo se desviar em um segundo em qualquer direção.
De acordo com a página de manual do rsync, isso deve ser bom o suficiente (tm) para o FAT32.
De acordo com a documentação que você citou (transformando 122 em 124, o que diabos), não é bom o suficiente.
Então, isso é inconclusivo.
Por experimentação, usando NTFS (-3g) e FAT32 no Linux, modify_window = 1 parece funcionar bem.
Minha configuração de teste foi assim:
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/
Portanto, um sistema de arquivos NTFS / FAT32 de 100M.
Crie mil arquivos com vários timestamps:
cd /tmp/ntfs
for f in {000..999}
do
sleep 0.0$RANDOM # widens the timestamp range
touch "$f"
done
Por exemplo:
# 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
De acordo com você, 20:19:10.011 deve sair como 2018-08-10 20:19:12.000 .
Então vamos ver o que acontece. Primeiro, copie todos esses arquivos para o FAT32.
# rsync -a /tmp/ntfs/ /tmp/fat32/
Em seguida, notei que os timestamps são realmente precisos, até você desmontar e montar novamente:
# umount /tmp/fat32
# mount -o loop fat32.img /tmp/fat32
Compare:
# 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
Então, isso praticamente parece ter sido chocado para mim. Não sei se o Windows faria da mesma maneira, mas é isso que acontece usando o Linux e o rsync.
O que o rsync faria ao copiar novamente:
# rsync -av --dry-run /tmp/ntfs/ /tmp/fat32
sending incremental file list
./
000
001
002
035
036
...
963
964
997
998
999
Portanto, há algumas lacunas na lista, mas, em geral, ele copia bastante muitos arquivos.
Com --modify-window=1 , a lista está vazia:
# rsync -av --dry-run --modify-window=1 /tmp/ntfs/ /tmp/fat32/
sending incremental file list
./
Então, pelo menos para o Linux, a página man é precisa. O deslocamento parece nunca ser maior que 1. (Bem, uma fração mais, mas isso também é ignorado).
Então, você deveria estar usando --modify-time=2 ? Não até que você possa mostrar experimentalmente que esta é realmente uma condição possível. Mesmo assim, é difícil dizer. Este é um truque horrível em primeiro lugar e quanto maior a janela de tempo, maior a probabilidade de que modificações genuínas sejam perdidas.
Mesmo o --modify-time=1 já ignora as alterações que não podem ser relacionadas à maneira como os carimbos de hora FAT32 são arredondados - já que ele ocorre em ambas as direções, mas o FAT32 é usado apenas em pisos. O rsync ignora isso ao copiar para FAT32 ser mais antigo), e vice-versa ao copiar de FAT32 (arquivos de destino só podem ser mais recentes).
Uma opção para lidar com isso melhor parece não existir.
Eu também tentei rastrear este comportamento nas fontes do kernel, infelizmente os comentários (no linux / fs / fat / misc.c) não dão muito para continuar.
/*
* 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)
*/
Então, de acordo com isso, o registro de data e hora do FAT usa 5 bits por segundo, portanto, você obtém apenas 32 estados possíveis, dos quais 30 são usados. A conversão é feita com uma simples troca de bits.
em fs / fat / misc.c :: fat_time_unix2fat ()
/* 0~59 -> 0~29(2sec counts) */
tm.tm_sec >>= 1;
Então 0 é 0, 1 é 0, 2 é 1, 3 é 1, 4 é 2 e assim por diante ...
em fs / fat / misc.c :: fat_time_fat2unix ()
second = (time & 0x1f) << 1;
Inversão do acima, e o 0x1f é o bitmask para pegar apenas os bits 0-4 do tempo FAT que representa 0-29 segundos.
Se isso for diferente do que deveria ser, não há nada nos comentários que eu possa ver.
Uma postagem interessante de Raymond Chen sobre por que o Windows se daria ao trabalho de arredondar os tempos: link
Okay, but why does the timestamp always increase to the nearest two-second interval? Why not round to the nearest two-second interval? That way, the timestamp change is at most one second.
Because rounding to the nearest interval means that the file might go backward in time, and that creates its own problems. (Causality can be such a drag.)
De acordo com isso, a ferramenta xcopy do Windows possui um sinalizador /D que diz "apenas copie os arquivos de origem se forem mais recentes que o arquivo de destino". Basicamente, o que rsync --update ou cp --update faria.
Reduzindo o tempo, fazendo com que os arquivos pareçam ser criados 1 segundo no passado, como acontece no Linux, os arquivos serão copiados novamente toda vez que você executar o comando. O tempo de arredondamento corrige isso.
OTOH, a solução do Windows, causa a mesma dor de cabeça ao copiar esses arquivos de volta. Ele copia arquivos que são feitos para serem mais recentes do que realmente são, e então você precisa ter cuidado para que o ajuntamento não aconteça duas vezes.
Não importa o que você faça, é sempre errado, um sistema de arquivos que não pode armazenar timestamps corretamente é apenas um incômodo.