~에 따르면마이크로소프트,
파일이 NTFS 드라이브에서 FAT 드라이브로 복사되면 일부 파일 타임스탬프 반올림이 발생해야 합니다. 파일 타임스탬프는 다음 짝수 초로 반올림됩니다.
(전단)
NTFS 타임스탬프: 7시간 31분 0초 001.
FAT 타임스탬프는 7시간 31분 2초 000이 됩니다.
그러나 man rsync말하다
--수정 창
두 개의 타임스탬프를 비교할 때 rsync는 타임스탬프가 수정 창 값 이상 차이가 나지 않는 경우 타임스탬프를 동일한 것으로 간주합니다. 일반적으로 0(정확한 일치의 경우)이지만 경우에 따라 더 큰 값으로 설정하는 것이 유용할 수도 있습니다. 특히, --modify-window=1은 MS Windows FAT 파일 시스템(2초의 시간 분해능을 나타냄)과 주고받을 때 유용합니다(최대 1초까지 시간 차이 허용).
--modify-window=2"반올림"을 수행하는 대신 "천장"을 수행하기 때문에 이것이 올바른 선택이라고 생각합니다 . 내가 맞는지 누가 말해 줄 수 있나요?
관련성 또는 관련성이 없는 정보:
제 환경에서는 FAT32 USB에 들어있는 파일의 mtime 해상도가 1초로 "바닥"이 다 되어있는데 왜그런지는 모르겠습니다. USB 형식은 fdisk및 입니다 mkfs -t fat -F 32. Linux Mint에서 Volumio로 파일 전송. 나는 타임스탬프를 확인하기 위해 date -r +%s.%N.
다시 채우다:
또 다른 정보를 찾았습니다.rsync를 위한 안정적인 메일 스레드설명하다
타임스탬프는 vfat에서 항상 문제입니다. 1~2초의 해상도를 가지므로 --modify-window=2가 일반적인 솔루션입니다.
그러나 이는 man rsync많은 권장 사항이 있는 StackExchange에서 허용되는 답변과 모순됩니다 --modify-window=1. 이제 나는 혼란스러워졌습니다.
답변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
위의 모든 수학은 fat32 파티션의 반올림/잘림/천장이 1초인 경우 --modify-window=1이것이 정답임을 증명합니다. 그럼에도 불구하고 내 fat32 파티션에서는 홀수 초가 포함된 파일을 찾을 수 없습니다...:
ls -Rla --time-style=full-iso | grep '[13579]\.000000000 ' | wc -l
하지만:
ls -Rla --time-style=full-iso | grep '[02468]\.000000000 ' | wc -l
거기에 많은 파일이 있다는 것을 보여줍니다.
나는 주장한다:--modify-window=2