기술 · 실용 가이드
Gzip “unexpected end of file” 오류? 다시 풀기 전에 받은 바이트부터 증명하세요
EOF는 잘린 다운로드, 중단된 스트림, 또는 분할 파일 한 조각을 완전한 아카이브로 읽은 결과일 수 있습니다. 원본을 보존하고 실제 실패 경로를 고치세요.
“gzip: unexpected end of file”은 압축 해제기가 바이트 스트림의 이른 끝을 만났다는 뜻일 뿐 원인을 알려 주지는 않습니다. tar 옵션을 바꿔 반복해도 도착하지 않은 데이터는 복구되지 않으며, 일부 파일이 풀렸다고 부분 아카이브를 신뢰할 수 있는 것도 아닙니다.
151,552바이트의 결정적 페이로드로 gzip 멤버 하나를 만들었습니다. 완전한 514바이트 멤버는 풀렸고 마지막 8바이트 트레일러를 제거하면 EOFError가 났습니다. 첫 257바이트 분할 조각도 EOFError였고 두 번째 조각만 읽으면 gzip 헤더가 아니었습니다. 두 조각을 순서대로 합치면 원래 514바이트 SHA-256과 페이로드 해시가 정확히 복원되었습니다.
이 통제 실험은 진단 순서를 뒷받침할 뿐 복구를 보장하지 않습니다. 알 수 없는 파일은 중간 손상, 바뀌는 URL, 미완성 생성, 여러 유효 멤버 연결, 다른 포맷 포장도 있을 수 있습니다. 실패한 바이트를 보존하고 가능하면 게시자의 체크섬이나 크기를 확보하세요.
재시도 전에 실패 증거를 고정하세요
파일을 새 증거 경로로 복사하고 바이트 수, SHA-256, 원본 URL 또는 객체 키, 응답 헤더, 다운로드 시각과 모든 조각 이름을 기록합니다. 두 번째 다운로드로 덮어쓰면 불안정한 전송을 보여 주는 차이가 사라집니다.
복사본에 gzip -t를 실행하고 종료 코드와 표준 오류를 보존합니다. 이 검사는 일부 파일 추출을 성공으로 여기지 않고 전체 스트림을 읽습니다. 신뢰할 수 없는 입력은 격리된 작업 디렉터리에서 검사하고 자동 추출을 피하세요.
다운로드, 스트림, 분할 세트, 생성 결과를 분리하세요
다운로드에서는 받은 크기와 해시를 게시자의 서명되거나 인증된 메타데이터와 비교합니다. 프록시가 HTML을 보냈는지, range 요청이 일찍 끝났는지, 재개가 호환되지 않는 바이트를 붙였는지 확인하고 새 이름으로 다시 받아 비교합니다.
스트림에서는 전송 완료와 압축 해제 오류를 함께 기록합니다. Node.js 사례는 같은 S3 객체를 읽으며 다른 지점에서 실패했습니다. 이는 스트림 완료, 재시도와 객체 정체성을 조사할 이유이지 큰 gzip이 본질적으로 잘못됐다는 증거는 아닙니다.
검증된 목록이 있을 때만 조각을 합치세요
제작자가 split을 사용했다면 각 조각, 예상 크기 또는 해시, 정렬 규칙을 확인합니다. Unix & Linux 사례의 part.000은 한 파일의 앞부분이므로 순서대로 합친 뒤에야 검사할 수 있습니다.
합친 결과는 새 파일에 쓰고 조각을 덮어쓰지 않습니다. 신뢰 가능한 체크섬, 해당 파일의 gzip -t, 실제 소비 프로그램 순으로 검사합니다. gzip 통과는 gzip 무결성만 증명하며 모든 애플리케이션 레코드나 tar 멤버의 존재를 증명하지 않습니다.
신뢰할 원본 바이트가 없으면 중단하세요
일부 파일이 나왔다는 이유로 아카이브를 승인하거나, 검사가 통과할 때까지 바이트를 자르거나, 오류를 숨기지 마세요. 보이는 실패가 조용한 누락으로 바뀝니다. 게시자나 상위 작업에서 새 불변 객체와 체크섬을 받아야 합니다.
수정 뒤에는 이전과 새 해시, 전송 또는 결합 변경, 전체 gzip 검사와 하위 검증을 기록합니다. 해결되지 않은 항목을 명시하고 권위 있는 원본이 없다면 출력을 완전본이 아닌 부분 결과로 설명하세요.
