The customer send us the dump for Exadata POC and this dump is unavailable to unzip :
[root@ed01db01 ]# unzip dmp.zip
error: Zip file too big (greater than 4294959102 bytes)
Archive: dmp.zip
warning [dmp.zip]: 10149171547 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [dmp.zip]: start of central directory not found;
zipfile corrupt.
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
Our unzip version is:
[root@ed01db01 ]# unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
The solution 1:
[root@ed01db01 ttelek]# funzip dmp.zip > dmp.dmp
[root@ed01db01 ttelek]# ls -l
-rw-r--r-- 1 root root 65195868160 May 13 11:24 dmp.dmp
-rw-r----- 1 oracle dba 14444138961 May 12 00:03 dmp.zip
[root@ed01db01 ttelek]# funzip
fUnZip (filter UnZip), version 3.94 of 17 February 2002
usage: ... | funzip [-password] | ...
... | funzip [-password] > outfile
funzip [-password] infile.zip > outfile
funzip [-password] infile.gz > outfile
Extracts to stdout the gzip file or first zip entry of stdin or the given file.
Our conclusion: the Exadata has the funzip by default, we don't install it intentionally.
The solution 2:
[root@ed01db01 ]# zcat dmp.zip > dmp.dmp
Exadata has zcat by default.
[root@ed01db01 ]# unzip dmp.zip
error: Zip file too big (greater than 4294959102 bytes)
Archive: dmp.zip
warning [dmp.zip]: 10149171547 extra bytes at beginning or within zipfile
(attempting to process anyway)
error [dmp.zip]: start of central directory not found;
zipfile corrupt.
(please check that you have transferred or created the zipfile in the
appropriate BINARY mode and that you have compiled UnZip properly)
Our unzip version is:
[root@ed01db01 ]# unzip
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
The solution 1:
[root@ed01db01 ttelek]# funzip dmp.zip > dmp.dmp
[root@ed01db01 ttelek]# ls -l
-rw-r--r-- 1 root root 65195868160 May 13 11:24 dmp.dmp
-rw-r----- 1 oracle dba 14444138961 May 12 00:03 dmp.zip
[root@ed01db01 ttelek]# funzip
fUnZip (filter UnZip), version 3.94 of 17 February 2002
usage: ... | funzip [-password] | ...
... | funzip [-password] > outfile
funzip [-password] infile.zip > outfile
funzip [-password] infile.gz > outfile
Extracts to stdout the gzip file or first zip entry of stdin or the given file.
Our conclusion: the Exadata has the funzip by default, we don't install it intentionally.
The solution 2:
[root@ed01db01 ]# zcat dmp.zip > dmp.dmp
Exadata has zcat by default.
i have a 96 gig zip file i cannot extract....
ReplyDeleteunzip 5.52.. yum says it is the latest...
what can i do to extract the file to the current directory???
funzip file.zip > /
?
I'm having an unzip 6 and a zip 3 (with which the zipfile was made) and it gives EXACTLY the same message.
ReplyDeleteOn the info-zip site, it says that even lower versions (of which unzip 5.52) do NOT have this limitation.
When running the ZIP file, I didn't see any error (but I only saw the last page).
Conclusion : still unreliable, when it comes to large files, even in 2014.
Note not a lot is said about 64-bit
jar xf test.zip
ReplyDelete