Por que `--modify-window=1` ao usar o comando `rsync`?

Apenas para evitar qualquer confusão sobre como o modify_window funciona, ele é verificado em qualquer direção. (Se você quiser ler isso no código-fonte, verifique util.c :: cmp_time().)

Que significa,

• se A for mais novo que B, verifica se A ainda é mais novo que B + modify_window.
• se B for mais novo que A, verifica se B ainda é mais novo 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 novo que B) ou 124 (tornando B mais novo que A).

O que acontece com modify_window = 1?

• Se A (123) for mais novo que B (122), verifica se A (123) ainda é mais novo que B (122+1 = 123).
• Se B (124) for mais novo que A (123), verifica se B (124) ainda é mais novo que A (123+1 = 124).

Em ambos os casos, é idêntico, portanto, modify_window = 1 é suficiente para que o tempo se desvie 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 FAT32.

De acordo com a documentação que você citou (transformando 122 em 124, 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 ficou 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 uma variedade de carimbos de data/hora:

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.011deve sair como 2018-08-10 20:19:12.000.

Então vamos ver o que acontece. Primeiro, copie todos esses arquivos para FAT32.

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

Então notei que os timestamps são realmente precisos, até que você desmonte e remonte:

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

Comparar:

# 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 parece que ficou no chão para mim. Não sei se o Windows faria da mesma maneira, mas é isso que acontece usando Linux e 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, existem algumas lacunas na lista, mas, em geral, seria copiado novamente 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
./

Portanto, pelo menos para 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ê deve usar --modify-time=2mesmo assim? Não até que você possa mostrar experimentalmente que esta é realmente uma condição possível. Mesmo assim, é difícil dizer. Este é um hack terrível em primeiro lugar e quanto maior a janela de tempo, maior a probabilidade de que modificações genuínas sejam perdidas.

Mesmo --modify-time=1já ignora as alterações que não podem estar relacionadas à maneira como os carimbos de data e hora do FAT32 são arredondados - uma vez que vai nas duas direções, mas o FAT32 apenas pisos, e o rsync ignora isso ao copiar para FAT32 (os arquivos de destino só podem ser mais antigos) e vice versa ao copiar do FAT32 (os arquivos de destino só podem ser mais recentes).

Uma opção para lidar melhor com isso parece não existir.

Eu também tentei rastrear esse comportamento nas fontes do kernel, infelizmente os comentários (em 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 timestamp FAT usa 5 bits por segundos, então você obtém apenas 32 estados possíveis, dos quais 30 são usados. A conversão é feita com um simples deslocamento 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;

Reverso do acima, e 0x1fé a máscara de bits 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 sobre isso nos comentários que eu pudesse ver.

Um post interessante de Raymond Chen sobre por que o Windows se daria ao trabalho de arredondar os tempos: https://blogs.msdn.microsoft.com/oldnewthing/20140903-00/?p=83

Ok, mas por que o timestamp sempre aumenta para o intervalo de dois segundos mais próximo? Por que não arredondar para o intervalo de dois segundos mais próximo? Dessa forma, a alteração do carimbo de data/hora é de, no máximo, um segundo.

Porque arredondar para o intervalo mais próximo significa que o arquivo pode voltar no tempo e isso cria seus próprios problemas. (A causalidade pode ser um empecilho.)

xcopyDe acordo com isso, a ferramenta do Windows possui um /Dsinalizador que diz "somente copie os arquivos de origem se forem mais recentes que o arquivo de destino". Basicamente o que rsync --updateou cp --updatefaria.

Arredondar o tempo para baixo, fazendo com que os arquivos pareçam ter sido criados 1 segundo no passado, como acontece no Linux, faria com que os arquivos fossem copiados novamente toda vez que você executasse o comando. O arredondamento do tempo corrige isso.

OTOH a solução Windows apenas lhe dá a mesma dor de cabeça ao copiar esses arquivos de volta. Ele copiaria arquivos que são feitos para serem mais novos do que realmente são, e então você tem que ter cuidado para que o roundup não aconteça duas vezes.

Não importa o que você faça, está sempre errado, um sistema de arquivos que não pode armazenar registros de data e hora corretamente é apenas um incômodo.

Toda a matemática acima prova que, se sua partição fat32 arredondar/truncs/ceils para 1 segundo, --modify-window=1é a resposta correta. No entanto: na minha partição fat32, não consigo encontrar nenhum arquivo com segundos ímpares ...:

ls -Rla --time-style=full-iso | grep '[13579]\.000000000 ' | wc -l

enquanto:

ls -Rla --time-style=full-iso | grep '[02468]\.000000000 ' | wc -l

mostra que há muitos arquivos lá.

eu fico com:--modify-window=2