rsync : --size-only와 --ignore-times의 차이
두 옵션의 차이점을 이해하려고 노력 중입니다.
rsync --size-only
과
rsync --ignore-times
기본적으로 rsync는 파일을 동기화해야하는지 여부를 결정하기 위해 타임 스탬프와 파일 크기를 모두 비교합니다. 위의 옵션을 사용하면 사용자가이 동작에 영향을 줄 수 있습니다.
두 옵션 모두 적어도 구두로 같은 결과를 가져 오는 것 같습니다 : 크기로만 비교 .
여기서 미묘한 것이 빠졌습니까?
rsync가 파일을 비교하는 방법에는 여러 가지가 있습니다. 신뢰할 수있는 출처는 rsync 알고리즘 설명입니다 : https://www.andrew.cmu.edu/course/15-749/READINGS/required/cas/tridgell96.pdf . rsync에 대한 wikipedia 기사 도 매우 좋습니다.
로컬 파일의 경우 rsync는 메타 데이터를 비교하고 소스와 대상간에 크기와 타임 스탬프가 일치하기 때문에 파일을 복사 할 필요가없는 것처럼 보이면 더 이상 보이지 않습니다. 일치하지 않으면 cp가 파일입니다. 그러나 메타 데이터는 일치하지만 파일이 실제로 동일하지 않으면 어떻게됩니까? 그렇다면 rsync가 의도 한대로 작동하지 않았을 것입니다.
동일한 크기의 파일이 여전히 변경되었을 수 있습니다. 한 가지 간단한 예는 "teh"를 "the"로 변경하는 것과 같이 오타를 수정하는 텍스트 파일입니다. 파일 크기는 동일하지만 수정 된 파일의 타임 스탬프가 더 최신입니다. --size-only는 "시간을 보지 마십시오. 만약 크기가 일치하면 파일이 일치한다고 가정합니다"라고 말하는데,이 경우 잘못된 선택입니다.
다른 한편으로 어제 실수로 큰 "cp -r A B"를 수행했지만 타임 스탬프를 유지하는 것을 잊었고 이제 역으로 "rsync B A"로 작업을 수행하려고한다고 가정합니다. cp'ed 모든 파일에는 어제 실제로 수정되지 않았지만 어제의 타임 스탬프가 있으며 rsync는 기본적으로 모든 파일을 복사하고 타임 스탬프를 어제로 업데이트합니다. --size-only는이 경우 친구가 될 수 있습니다 (위의 예를 모듈로).
--ignore-times는 파일의 수정 시간이 동일한 지 여부에 관계없이 파일을 비교하도록 말합니다. 위의 오타 예제를 고려해보십시오. 오타를 고쳤을뿐만 아니라 "touch"를 사용하여 수정 된 파일이 원본 파일과 동일한 수정 시간을 갖도록 만들었습니다. 그런 식으로 은밀하다고 가정 해 봅시다. 음 --ignore-times는 크기와 시간이 일치 하더라도 파일의 차이를 처리합니다 .
rsync가 체크섬으로 파일을 비교할 수도 있다는 사실이 없습니다.
--size-only
즉, 타임 스탬프가 다르더라도 rsync는 크기가 일치하는 파일을 건너 뜁니다. 즉, 기본 동작보다 더 적은 수의 파일을 동기화합니다. 전체 파일 크기에 영향을주지 않는 변경 사항이있는 파일은 누락됩니다. 파일을 변경하지 않고 파일의 날짜를 변경하는 것이 있고 해당 파일이 변경되지 않았 음을 발견하기 위해 해당 파일을 체크섬하는 데 rsync가 많은 시간을 소비하는 것을 원하지 않는 경우이 옵션을 사용할 수 있습니다.
--ignore-times
즉, 타임 스탬프와 파일 크기가 일치하더라도 rsync는 모든 파일을 체크섬합니다. 이는 기본 동작보다 더 많은 파일을 동기화한다는 것을 의미합니다. 파일 크기가 같고 수정 날짜 / 시간이 원래 값으로 재설정 된 경우에도 파일에 대한 변경 사항이 포함됩니다. 모든 파일을 체크섬하면 디스크에서 완전히 읽어야하므로 속도가 느릴 수 있습니다. 일부 빌드 파이프 라인은 타임 스탬프를 저장하는 tar 파일에 압축 된 경우와 같이 최종 빌드 파일이 비트에 대해 재현 가능한 비트인지 확인하기 위해 타임 스탬프를 특정 날짜 (예 : 1970-01-01)로 재설정합니다.
짧은 대답은 --ignore-times
이름이 의미하는 것 이상 을 수행한다는 것입니다. 시간과 크기를 모두 무시 합니다 . 반대로, --size-only
정확히 말한대로합니다.
긴 대답은 rsync
파일이 오래된 것인지 결정하는 세 가지 방법 이 있다는 것입니다.
- 소스와 대상의 크기를 비교하십시오.
- 소스와 목적지의 타임 스탬프를 비교합니다.
- 소스와 대상의 정적 체크섬을 비교합니다.
이러한 검사는 데이터를 전송하기 전에 수행됩니다. 특히 이것은 정적 체크섬이 스트림 체크섬과 구별된다는 것을 의미합니다. 나중에 데이터를 전송하는 동안 계산됩니다.
기본적으로 rsync
1과 2 만 사용합니다. 1과 2는 하나의으로 함께 획득 할 수 stat
있지만 3은 전체 파일을 읽어야합니다 (전송을 위해 파일을 읽는 것과는 별 개임). 수정자가 하나만 지정되었다고 가정하면 다음을 의미합니다.
를 사용
--size-only
하면 1 개만 수행됩니다. 타임 스탬프와 체크섬은 무시됩니다. 파일 크기가 양쪽 끝이 동일하지 않으면 파일이 복사됩니다.를 사용
--ignore-times
하면 1, 2 또는 3이 수행되지 않습니다. 파일은 항상 복사됩니다.를 사용 하면 1 외에
--checksum
3이 사용 되지만 2는 수행 되지 않습니다 . 크기와 체크섬이 일치하지 않으면 파일이 복사됩니다. 체크섬은 크기가 일치하는 경우에만 계산됩니다.
Scientific Linux 6.7 시스템에서 rsync의 man 페이지는 다음과 같이 말합니다.
--ignore-times don't skip files that match size and time
내용은 동일하지만 생성 날짜가 다른 두 개의 파일이 있습니다.
[root@windstorm ~]# ls -ls /tmp/master/usercron /tmp/new/usercron
4 -rwxrwx--- 1 root root 1595 Feb 15 03:45 /tmp/master/usercron
4 -rwxrwx--- 1 root root 1595 Feb 16 04:52 /tmp/new/usercron
[root@windstorm ~]# diff /tmp/master/usercron /tmp/new/usercron
[root@windstorm ~]# md5sum /tmp/master/usercron /tmp/new/usercron
368165347b09204ce25e2fa0f61f3bbd /tmp/master/usercron
368165347b09204ce25e2fa0f61f3bbd /tmp/new/usercron
로 --size-only
, 두 파일은 동일하게 간주된다 :
[root@windstorm ~]# rsync -v --size-only -n /tmp/new/usercron /tmp/master/usercron
sent 29 bytes received 12 bytes 82.00 bytes/sec
total size is 1595 speedup is 38.90 (DRY RUN)
로 --ignore-times
두 파일이 다른 간주된다 :
[root@windstorm ~]# rsync -v --ignore-times -n /tmp/new/usercron /tmp/master/usercron
usercron
sent 32 bytes received 15 bytes 94.00 bytes/sec
total size is 1595 speedup is 33.94 (DRY RUN)
그래서 --ignore-times
전혀 효과 가없는 것 같습니다 .
참고 URL : https://stackoverflow.com/questions/13778889/rsync-difference-between-size-only-and-ignore-times
'Programming' 카테고리의 다른 글
참조 할당은 원자 적이므로 Interlocked.Exchange (ref Object, Object)가 필요한 이유는 무엇입니까? (0) | 2020.08.17 |
---|---|
C #에서 대리자를 언제 사용합니까? (0) | 2020.08.17 |
try / catch / throw와 try / catch (e) / throw e의 차이점 (0) | 2020.08.17 |
sed가 모든 항목을 대체하지 않는 이유는 무엇입니까? (0) | 2020.08.17 |
Android에서 고유 한 장치 하드웨어 ID를 얻는 방법은 무엇입니까? (0) | 2020.08.17 |