복사 된 파일이 원본과 동일한 지 확인하기 위해 모든 단일 바이트를 읽어야합니까?

최근에 Total Commander라는 프로그램을 배웠습니다. 그것은 Windows 탐색기 대체품이며 파일을 복사하는 자체 기능이 있습니다. 파일이 CRC를 계산하는 대신 파일이 동일한 지 여부를 확인하기 위해 원본과 사본 모두에서 한 번에 하나씩 모든 단일 바이트를 확인합니다.

내 질문은 : 이것이 필요합니까? CRC 나 다른 기술이 잘못 될 수 있습니까? 프로그래머로서이 완벽하지만 느린 시스템을 시도하고 구현해야합니까, 아니면 너무 극단적입니까?

두 파일에서 CRC (또는 더 나은 sha1sums)를 계산하려면 모든 바이트를 읽어야합니다. 바이트 단위 비교를 수행하는 경우 불일치가 발생하자마자 종료 할 수 있으며 동일한 체크섬을 갖는 두 개의 서로 다른 파일에 대해 걱정할 필요가 없습니다 (sha1sum에서는 사라질 수는 없지만) . 따라서 로컬에서 비교를 수행하는 경우 바이트 체크 비교는 적어도 체크섬 비교만큼 빠릅니다 (아직 체크섬을 계산하지 않은 경우).

반면, 체크섬 비교는 동일한 컴퓨터에없는 파일을 비교할 때 유용합니다. 체크섬은 로컬로 계산할 수 있으며 네트워크를 통해 전체 내용을 전송할 필요가 없습니다.

하이브리드 접근법도 가능합니다. 예를 들어, 한 번에 한 청크 씩 두 파일의 체크섬을 계산하고 비교할 수 있습니다. 이렇게하면 전체 파일을 읽는 것을 피할 수 있으며 ( 다른 경우 ) 전체 파일을 네트워크를 통해 전송하지 않아도됩니다. rsync를 프로토콜은 이 같은 작업을 수행합니다.

Dave Rager가 그의 답변에서 언급했듯이 간단한 CRC를 사용하면 충돌의 가능성이 높아집니다. 최소한 sha1sum 또는 더 최근의 것을 사용하십시오 . (나만의 해싱 알고리즘을 만들려고하지 마십시오. sha1sum을 개발 한 사람들은이 둘에 대해 훨씬 더 많이 알고 있습니다.)

충돌 가능성에 관해서는 sha1sum과 같은 괜찮은 해시를 사용하면 누군가가 sha1sum이 충돌하는 파일을 고의적으로 고가로 생성 하지 않는 한 걱정할 필요 가 없습니다 ( 처음으로 이것을 쓸 때 충돌을 일으킬 수 없었습니다) 하지만 진전이 이루어지고 있습니다 ). Scott Chacon의 "Pro Git" , 섹션 6.1 인용 :

다음은 SHA-1 충돌 발생에 대한 아이디어를 제공하는 예입니다. 지구상의 65 억 명의 사람들이 프로그래밍을하고 매초마다 전체 리눅스 커널 역사 (1 백만 개의 Git 객체)와 동등한 코드를 생성하여 하나의 거대한 Git 저장소로 밀어 넣는다면 5 년이 걸릴 것입니다. 이 저장소에는 단일 SHA-1 오브젝트 충돌의 50 % 확률을 갖기에 충분한 오브젝트가 포함되어 있습니다. 프로그래밍 팀의 모든 구성원이 같은 날 밤 관련없는 사건에서 늑대에 의해 공격 당하고 살해 당할 가능성이 더 높습니다.

요약 :

바이트 별 비교는 로컬 비교에 적합합니다. sha1sum은 원격 비교에 적합하며 오 탐지 가능성이 크지 않습니다.

여기에 다른 생각이 있습니다.

두 개의 서로 다른 파일이 동일한 CRC를 가질 가능성이없는 경우 확장명은 모든 파일을 고유 한 CRC로 나타낼 수 있음을 의미합니다 .CRC가 원본 파일보다 작 으면 무손실 압축 형식을 나타냅니다. 그렇지 않으면 동일한 바이트 수를 비교할 것이므로 원본 파일을 비교하는 것만으로도 좋습니다.

이론적으로는 비교에 필요한 바이트 수를 줄이기 위해 비교의 양쪽에 무손실 압축을 사용할 수 있지만 더 많은 사이클을 낭비하고 압축을 수행하기 위해 두 파일의 모든 바이트를 읽어야하기 때문에 바보입니다 . 즉, 모든 바이트 (및 순서)를 무손실 압축 방식으로 인코딩하려면 먼저 그것을 읽고 알고리즘에 연결해야합니다. 게임 끝.

다음은 비유입니다.
문자별로 비교하지 않고 두 개의 인쇄 된 문서가 동일한 지 여부를 신속하게 결정하려면 문서의 각 줄에서 문자 수를 비교할 수 있습니다. 카운트가 모두 일치하면 문서가 동일하다는 확률이 크게 향상되지만 아무도이 방법을 사용하여 모든 문자가 동일하다고 확신 할 수는 없습니다.

동일한 파일을 확인하는 유일한 완벽한 방법은 바이트 비교를위한 바이트입니다. 공정한 근사치가되는 다른 방법은 파일의 MD5와 같은 해시를 계산하고 비교하는 것입니다. 해시 충돌이있을 수 있지만 가능성은 낮습니다.

바이트 비교를위한 바이트가 비교를 수행 할 때 두 파일의 해시를 계산하는 것보다 빠를 것이라고 생각합니다. 그러나 응용 프로그램에서 해시를 미리 계산하고 파일에 대한 메타 데이터를 저장하면 해시를 비교하는 것이 훨씬 빠릅니다.

CRC는 해시가 아닌 오류 감지 메커니즘 일 뿐이므로 갈 길이 멀다. (또는 충돌 가능성이 많은 해시 불량)

두 파일이 100 % 동일하기 위해서는 실제로 바이트를 확인해야합니다.

왜? 해시 충돌, 그 이유! 해싱에 사용 된 알고리즘에 따라 충돌이 다소 발생할 수 있지만 더 적은 가능성은 없습니다. 다음 단계를 수행하십시오.

1. 파일 크기 확인
2. MIME 유형 확인
3. 해시 확인
4. 몇 가지 임의의 오프셋을 확인하고 비트를 비교

두 파일이 동일하다는 확신을 매우 확실하게 제공하지만 손에 충돌이 발생할 가능성은 매우 적습니다. 당신이 당신의 비교와 함께 가고 싶은 선택은 상황에 따라 결정됩니다.

다른 사람들이 말했듯이 두 파일이 동일한 시스템에 있으면 바이트 단위 비교가 더 빠릅니다. 많은 파일을 비교하려는 경우 파일이 회전하는 스토리지에있을 경우 해싱이 더 나은 대답이되는 지점에 도달합니다.

모든 데이터를 쉽게 사용할 수없는 경우 해싱이 실제로 빛납니다. 예를 들어, 파일이 다른 시스템에 있습니다. 또한 계산 결과를 저장하고 나중에 참조 할 수 있습니다. (이 보고서는 이전 보고서와 동일합니까? 보고서를 해시로 저장하면 다음 보고서를 만들 때 간단히 해시를 비교할 수 있습니다. 이전 보고서를 읽을 필요는 없습니다. ' 심지어 사본을 준비해야합니다.)

제공된 파일 비교 유틸리티를 운영 체제와 함께 사용하거나 파일 비교 도구를 사용해야한다고 생각합니다 ( wiki-file 비교 도구 참조). )를 사용하여 @Glenn Nelson에 의해 요약 된 파일 속성을 확인한 후 내용을 비교해야한다고 생각합니다.

CRC가 100 % 정확하다고 생각하지 않으며 파일 길이에 따라 정확도가 떨어질 것이라고 생각합니다. 또한 많은 테스트가 필요할 수 있으므로 처음부터 작성하지 않는 것이 좋습니다.

복사 된 파일이 원본과 동일한 지 확인하기 위해 모든 단일 바이트를 읽어야합니까? 네 100 % 확신합니다

복사 된 파일이 원본과 동일하지 않은지 확인하기 위해 모든 단일 바이트를 읽어야합니까? 아니

따라서 동일하지 않은 것을 신속하게 확인하려면 먼저 파일 크기와 같은 메타 데이터와 OS / 파일 시스템 / 저장소에서 이미 유지 관리 하고있는 모든 체크섬 / CRC 또는 MIME 유형을 확인하십시오 . 해당 시스템에 의해 사전 계산되므로 비교시이 비용을 지불하지 않습니다.

테스트가 통과되면 100 % 확실 해야하는 경우 여전히 모든 바이트를 개별적으로 비교해야하지만 현대 파이프 라인 CPU에서는 여러 스레드와 가능한 프로세서 / CPU를 사용하면 큰 파일의 블록 비교가 실제로 빠릅니다. 프로세스가 효율적이기 때문에 고도로 병렬화 가능. 각 바이트를 포함하는 모든 종류의 수학적 계산보다 훨씬 빠릅니다 (일부 알고리즘은 병렬화 가능하지만 쉽지는 않습니다). 파이프 라인 된 CPU가 마이크로 코드 또는 하드웨어 (실제로 빠름)에서 메모리의 블록 비교 작업을 수행 할 수 있고 디스크-메모리 하위 시스템은 메모리에서 / 파일로 대량의 파일 블록을 가져올 수 있도록 최적화되어 있기 때문입니다. 하드웨어. 응용 프로그램이 이런 종류의 작업을 정기적으로 수행하고 알려진 성능 병목 현상 인 경우 OS 및 하드웨어의 병렬화 기능을 활용하는 잘 작성된 다중 스레드 코드로 구현하는 것이 좋습니다. 이).

각 파일을 한 번 처리하고 나중에 여러 번 비교 (요약 된 ""캐시 "] 또는 요약 된"압축 된 "(JohnFX가 말한대로) 분석 결과)를 수행하려는 경우에만 그렇게하면 큰 이점이 있습니다. 그때까지도 차이를 증명하기 위해서만 (아마도); 동일성을 증명하려면 여전히 바이트 단위 비교를 수행해야합니다.