0

I have a 7 GB directory on my server and I want to download it to my PC. I've archived it with this command:

zip -9 -r sc.zip FOLDER/

I downloaded it to my PC . But ZIP file larger than 4 GB gives File too large error because I'm using FAT32. So I've downloaded 4294966367 bytes (about 4G) of the zip file and download stopped. Is it possible to rearchive the folder with 2 parts but first part will be exactly 4294966367 bytes and second part must be start from 4294966368th byte. After this, I hope I'll just need to download 2nd part and use previous downloaded 4 GB file as first part.

Shortly, I've already downloaded 4 GB of a zip, now I don't want to redownload it from zero. Is it possible to rearchive directory starting from 4th GB?

1st update: I know I can use -s parameter but it's getting minimum kilobytes, not bytes.

2nd update: I've split large .zip file with this command:

split -b 4294966367 -d sc.zip sc-part

Now there are sc-part00 and sc-part01. I've downloaded these 2 files and I joined them into one .zip file with this command:

cat sc-part* > file.zip

However, there's an error when I try to unzip it:

Error

  • 1
    Splitted zip file with this code : split -b 4294966367 -d sc.zip sc-part and now downloading 2nd part. I'll combine them into one file with this command : cat sc-part* > sc.zip I'll send it as answer if it works. – Eray May 19 '15 at 23:10
  • cat sc-part* > sc.zip cat: stdout: File too large I couldn't generate .zip file from splitted parts because it's exceeding 4Gb limit :)) – Eray May 20 '15 at 3:20
  • 1
    Okay, this is ask UBUNTU, when did we start supporting OS X And not give them crop for being nit only off topic but off operating system/kernel? – heypaleblue Jun 7 '15 at 12:52
  • @heypaleblue Looks like he's using a MacBook Air, but it's stated nowhere that he's using OSX, either on the PC or on the server. That output might well come from unzip running on Ubuntu on a MacBook Air – kos Jun 10 '15 at 4:26
1
+25

warning [son.zip]: 3201769768 extra bytes at beginning or within zipfile

You have: 7GB full file split to 2 parts, 1st 4GB and 2nd 3GB. So it seems to me that unzip couldn't find the zip magic byte till it reach 3201769769. If you check precisely 3201769768 is the size of the 2nd part.

Basically, you swapped the order of the parts when joined with cat. To check:

  • Try swapping parts: cat sc-part01 sc-part00 > file.zip
  • Check their checksums md5sum sc-part* for the ones in server and the ones in local machine.

BTW, there is many ways to spit file in a defined byte. Example:

  • tail -c <remaining-size> <source-file> > <destination-file>
  • dd if=<source-file> iflag=skip_bytes skip=<number-of-bytes-to-skip> of=<destination-file>
  • 1
    Everything stated here is correct / useful, +1. However sc-part* always expands to the correct order for me. I also tried to move the parts forth and back to see if the expansion order its dependent on the order in which the filesystem stores the files, but nothing ever changed, so it seems like that is not the problem – kos Jun 10 '15 at 4:32
  • 1
    @kos, You are right. I didn't check this before, it result are sorted in alphabetical order. Here is one question about this serverfault.com/questions/122737/… – user.dz Jun 10 '15 at 9:47
0

Easy answer: split the directory into two equalish sized directories and zip each of them. Then unzip them and recombine them on your PC.

I see you're on a Mac. try this:

scp -R [username]@[server_ip]:[directory_path] ./

That should do the whole thing over SSH, assuming that you have that set up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.