Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I had to split this 2.6 GB zip-file in order to send it thru a slow uplink. I did this:

split -b 879m BIGFILE.zip

This created xaa, xab & xac which I uploaded to the remote server. After the transfer finished I verified each one of these 3 pieces with md5sum (both on my local system and on the server):

md5sum xaa
md5sum xab
md5sum xab

All of the 3 hashes were identical to that of the 3 ones on my system so the transfer went well. Now, on the remote system, when I do this:

cat xa* > BIGFILE.zip

...then I verify the hash of this BIGFILE.zip (on both systems):

md5sum BIGFILE.zip

...and both of them match.

Now comes the interesting part. When I try to list the contents of the zip file I get an error:

unzip -l BIGFILE.zip

I get:

Archive:  BIGFILE.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of BIGFILE.zip or
        BIGFILE.zip.zip, and cannot find BIGFILE.zip.ZIP, period.

This is totally weird. I'm using the same version of "unzip" on both systems. When I use the "unzip -l" on my local system it works.

Thanks for any help. JFA

share|improve this question
1  
What happens if you do zip -T on both files? –  Dennis Williamson Dec 2 '09 at 16:44
    
Thanks Dennis. I didn't know about the -T option. If I had known it, I probably wouldn't start this thread as indeed the validation fails on both files (locally and on remote system). Basically I assumed my local file was ok by doing "unzip -l" (which provided the correct output) but this didn't work on the server. Now I know abuot -T... Thanks. –  JFA Dec 3 '09 at 15:50

3 Answers 3

up vote 6 down vote accepted

Identical MD5 hashes suggest that the transfer has worked well.

More than 2G filesize sounds suspiciously like some pointer size issue - maybe the zip in question doesn't handle that well? more than (ca) 2G would be a negative number in 32 bit... Can you unzip the file on the system where you zipped it? Do both systems differ? Is one 64bit, the problematic 32 bit? What are the filesystems on both systems? Can you find another zip utility?

If you have a chance to retransmit the content, you might want to use tar.gz or keep file size lower than that value. gzip compressed content should handle this better. Zip stores the contents (index) at the end of the file.

Edit: Yup, see here:

In practice, the real limit may be 2 GB on many systems, due to UnZip's use of the fseek() function to jump around within an archive. Because's fseek's offset argument is usually a signed long integer, on 32-bit systems UnZip will not find any file that is more than 2 GB from the beginning of the archive [...]

share|improve this answer
    
+1 Brilliant. Great thinking! –  Dennis Williamson Dec 3 '09 at 3:58
    
Thanks Olaf! Right on! That's it! Both systems are 32-bit so indeed the 2GB applies. My mistake was "assuming" that my original file was OK by doing "unzip -l" (which works...it prints out the whole contents of the file) but when I tried (locally) to unzip the file I got an error. Now, on why the "unzip -l" worked locally and not on the server I don't know nor I'm not interested. The thing is that both zip files won't work and the main thing is that the original one - being more than 2GB - was already crippled. Thanks again Olaf! –  JFA Dec 3 '09 at 15:48

You should have used rsync instead. split is gheeetto. That said I have no idea what's wrong with your problem. Oh .. wait ... you can use rsync now. It will only transfer the difference between the files. Assuming you have ssh access on the remote machine:

rsync -Pvz BIGFILE.zip remotehostname:/path/to/BIGFILE.zip

... and you're done.

share|improve this answer
    
The checksums indicate that the file was transmitted completely and correctly. –  Dennis Williamson Dec 3 '09 at 3:57

How did you transfer file files? If you did it via FTP ASCII mode will hose the files. You may be able to use the -F flag of unzip to correct this but don't bet on it.

You may need to retransmit the files-I'd recommend doing it via scp

share|improve this answer
    
If the files got mangled during transmission then the checksums wouldn't match. –  Dennis Williamson Dec 3 '09 at 3:57

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.