비슷한 문제가있는이 스레드를 발견했습니다. 버그 보고서의 제목은 다음과 같습니다. unzip이 5.4GB ZIP에서 "처음 또는 zipfile 내의 추가 바이트"로 실패합니다 . 제안 된 수정 사항 중 하나는 .zip
파일 에서이 명령을 사용하는 것 입니다.
$ zip -FFv foo.zip --out fixed.zip
예제 실행
$ zip -FFv foo.zip --out fixed.zip
Fix archive (-FF) - salvage what can
Found end record (EOCDR) - says expect single disk archive
Scanning for entries...
Local ( 1 0): copying: d1/f1 (651734 bytes)
Local ( 1 651817): copying: d1/d2/ (0 bytes)
Local ( 1 651905): copying: d1/d2/f3 (80 bytes)
Local ( 1 652083): copying: d1/f23 (891 bytes)
Local ( 1 653021): copying: d1/f27 (8764 bytes)
Local ( 1 661837): copying: d1/f24 (14818 bytes)
Local ( 1 676709): copying: d1/f25 (17295 bytes)
...
Cen ( 1 5488799949): updating: d1/f13
Cen ( 1 5488800052): updating: d1/f14
Zip64 EOCDR found ( 1 5488800155)...
Zip64 EOCDL found ( 1 5488800211)...
EOCDR found ( 1 5488800231)...
$ echo $?
0
지퍼의 -FF 스위치
zip 맨 페이지에서 발췌
-FF
--fixfix
Fix the zip archive. The -F option can be used if some
portions of the archive are missing, but requires a reasonably
intact central directory. The input archive is scanned as
usual, but zip will ignore some problems. The resulting
archive should be valid, but any inconsistent entries will be
left out.
When doubled as in -FF, the archive is scanned from the
beginning and zip scans for special signatures to
identify the limits between the archive members. The single
-F is more reliable if the archive is not too much damaged, so
try this option first.
If the archive is too damaged or the end has been truncated,
you must use -FF. This is a change from zip 2.32, where the
-F option is able to read a truncated archive. The -F option
now more reliably fixes archives with minor damage and the -FF
option is needed to fix archives where -F might have been
sufficient before.
...
ftp
에서 BINARY 모드가 아닌 ASCII 모드 로 전송 되었고 일부 바이트가 추가 되었기 때문입니다.ftp
어떤 단계에서든 사용한 경우ftp
'put'또는 'get'전에 'bin'명령을 사용하여 다시 실행하십시오 .