저는 rsync한동안 Android를 사용하여 Linux 시스템의 원격 NTFS 파일 시스템에 휴대폰을 백업해 왔습니다.
최근 NTFS 파일 시스템이 포함된 HDD가 실패하기 시작했습니다(또는 "I/O 오류"가 발생함). 그래서 모든 파일을 새 HDD와 새 NTFS 파일 시스템에 복사할 기회를 얻었습니다. 이번 경우에는 Windows용 "FastCopy v2.11" 도구를 사용했습니다.
내 문제는 rsync "테스트 실행"을 수행할 때 이미 원격 rsync 폴더에 있는 파일을 다시 복사하려고 한다는 것을 알 수 있다는 것입니다. 예를 들어 "-iv"를 사용하여 실행하면 다음과 같은 출력이 표시됩니다.
<f..t...... extSdCard/foo/bar
내가 이해한 바에 따르면 이는 rsync가 타임스탬프 차이로 인해 이 파일을 원격 rsync에 복사하려고 한다는 것을 의미합니다.
신기하게도 Android용 "Astro"를 사용하여 로컬 파일 속성을 보면 파일의 크기, 수정 시간, MD5 체크섬이 원격 파일( ls -l수정 시간을 확인하는 데 사용됨)과 정확히 동일한 것을 알 수 있습니다.
최근에 이전 NTFS 파일 시스템에서 원격 rsync 파일을 복사한 경우 원격 파일의 ctime이 다릅니다(사용됨 ls -lc).
원격 ctime을 보고 계시나요 rsync? 그렇다면 이것을 사용하거나 rsync수정할 수 있는 방법이 있습니까 ntfs-3g?
답변1
기본적으로 rsync는 파일 비교를 위해 mtime/ctime 및 크기에 의존하지만 이 플래그를 사용하면 -c이를 무시하고 콘텐츠 체크섬을 사용합니다.
문제는 이 방법이 훨씬 느릴 수 있다는 것입니다(모바일 장치에서 이러한 체크섬을 계산하는 것은 매우 비쌀 수 있음). 이제부터는 항상 이렇게 실행해야 할 수도 있으므로 체크섬 없이 작동하도록 두는 것이 합리적일 수 있습니다. 한 번 실행하고 기본적으로 사용되는 mtime/ctime/size 비교 방법을 기반으로 모든 것을 다시 복사하도록 하십시오. 그러나 최소한 다음번에는 체크섬을 계산하는 데 시간을 소비하지 않을 것입니다.
답변2
방금 빠른 실험을 수행했습니다. rsync는 mtime을 비교하고 ctime을 무시합니다(적어도 Mac에서는). 안타깝게도 Windows 파일 시스템에는 ctime만 있으며 atime 및 mtime에 대해 ctime도 반환합니다.
이것이 rsync가 복사할 필요가 없는 Windows 파일 시스템에서 파일을 복사하는 데 매우 공격적인 이유입니다. Unix 파일의 mtime은 Windows 파일의 "ctime"과 비교됩니다.