gzip -t가 잘린 다운로드 오류를 100% 감지할 수 있습니까?

상상하다: 단일 1g CSV.gz가 FTP 폴더에 기록되고 있습니다. 그 사이에 내 클라이언트 컴퓨터는 SFTP를 통해 폴더에 연결하고 해당 폴더를 끌어내리려고 합니다.

묻다: 일단 파일을 얻은 후에는 클라이언트 측에서 얻은 겉보기 길이에 관계없이 gzip -t부분 파일을 감지하고 잘림이 발생하는 위치에 관계없이 실패할 수 있습니까?

압축 해제 또는 -t'esting은 조각이 갑자기 끝날 때 가능한 잘림 지점의 99%에서 오류가 발생할 것이라고 생각합니다. 하지만 gz 구조에는 gzip이 예기치 않게 성공을 보고하는 깨끗한 절단 지점이 있습니까?

테이블에 없는 완화(이 중 하나가 작동한다면 위의 질문을 할 필요가 없기 때문입니다.)

1. 다른 네트워크 요청을 통해 파일 길이 또는 md5를 가져옵니다.
   1. FTP를 통해 파일 길이를 폴링하는 것은 서버가 때때로 zip 스트림에 블록을 쓸 수 있기 때문에 그리 좋지 않습니다. 일괄 작업이 파일 핸들을 닫기 전에 이를 완전한 데이터 세트로 착각하는 것은 분석에 치명적일 것입니다.
   2. 배치 작업을 통한 최종 파일 길이 또는 해시를 고려하면 이 문제는 더 이상 필요하지 않지만 이는 (이 문제에 대해) 존재하지 않을 수 있는 구현 부담을 팀에 가합니다.
2. 하루 중 서로 다른 시간에 읽기/쓰기를 예약하면 경합을 피할 수 없습니다.
3. 서버가 원자적 이동 작업을 사용하고 있지 않습니다.
4. CSV 행/열 개수는 모든 스냅샷과 통합마다 변경됩니다. 이 문제에 대해 gzip으로 압축된 파일은 불투명한 바이너리 BLOB이라고 말할 수도 있습니다.
5. 게임에 클라이언트가 없습니다 => SFTP 네트워크 오류입니다. (이러한 내용은 캡처되고 처리됩니다. 내 관심사는 서버에서 일괄 작업 중에 가끔 작성되는 파일을 읽는 것입니다.)
6. SFTP 대신 RESTful API를 사용하세요.

기존 SO를 찾을 수 없습니다.

여러 가지 SO가 언급되었습니다.다루다잘렸지만 모든 문제에 대해 전체 워크플로를 안정적으로 실패시켜야 하는 것과 비교하여 손실이 허용되는 환경에서. (저는 의료데이터 환경에서 계산을 하기 때문에 잘못된 통계를 퍼뜨리느니 차라리 서버를 멈추고 불이 붙는 편이 낫습니다.)

• gzip: 예기치 않은 파일 끝 - 파일 읽는 방법정반대입니다. 사용 사례에 문제가 되지 않기 때문에 EOF 오류를 억제하려고 합니다.
• gzip을 사용할 때 스크립트에서 예기치 않은 파일 끝이 나타나는 이유는 무엇입니까?단지 posix 스트림의 끝이 의도적으로 삽입되었을 뿐이며 head"오탐이 가능한가?"라는 내용은 다루지 않습니다.
• 출력 파이핑 시 zcat/gzip 오류 아주 근접한, 그러나 "이 오류가 발생한다고 보장됩니까?"라고 묻지 않습니다.
• 잠재적으로 잘릴 수 있는 gzip 로그 파일 병합또한 종료된 배치 작업의 부분 파일을 처리하지만 여전히 보장된 오류 대신 읽을 수 없는 일부 줄이 발생하므로 닫습니다.