23

I've been struggling with this for a couple days so I'm hoping someone on SE can help me.

I've downloaded a large file from Dropbox using wget (following command)

wget -O folder.zip https://www.dropbox.com/sh/.../.../dropboxfolder?dl=1

I'm sure it's a zip because 1), file dropboxfolder.zip yields dropboxfolder.zip: Zip archive data, at least v2.0 to extract, and 2) the download and extraction works find on my Windows machine.

When I try to unzip to the current directory using unzip dropboxfolder.zip, on Linux, I get the following output:

warning:  stripped absolute path spec from /  
mapname:  conversion of  failed     
creating: subdir1/
creatingL subdir2/
extracting: subdir1/file1.tif 
error: invalid zip file with overlapped components (possible zip bomb)

I'm unsure what the issue is, since as I said it works fine on Windows. Since the zip is rather large (~19GB) I would like to avoid transferring it bit by bit, so I would be very thankful for any help. I've run unzip -t but it gives the same error. When listing all the elements in the archive it shows everything as it should be. Could it be an issue with the file being a tif file?

holy_schmitt
  • 333
  • 1
  • 2
  • 7
  • 3
    You could compute the md5 or sha1 sum of the zip file you downloaded to the linux machine and the one you downloaded to the windows machine. Then you can compare these hashes and see if you have the exact same file. Maybe there was an error during downloading the file. – Lucas Feb 13 '21 at 22:16
  • Does it happen with smaller folders? It would be interesting if you were able to post a smaller sample `.zip` which triggers the same error. –  Feb 13 '21 at 22:23
  • Can't get to this today, I'll check with a smaller .zip tomorrow and give an update. Thanks for the suggestion! – holy_schmitt Feb 14 '21 at 03:35
  • 1
    I checked with a smaller zip and it worked, so it seems it is a question of the zip size. Any new thoughts on what could fix this? For now I will try the approach below, but I will have to download a very large amount of data (~100's of GB) in the near future, so would like to find a general solution if possible. – holy_schmitt Feb 15 '21 at 21:55

3 Answers3

38

I had the exact same issue with dropbox, wget and zip. I used an alternative compressing tool and extracted the file with:

7z e file.zip
zs11
  • 496
  • 4
  • 6
16

I had the same issue for unzipping a large file (~6 GB). Solved it with this:

jar xf your_file.zip

I hope it helps!

Cheers,

Julian
  • 161
  • 1
  • 3
2

You should try this answer.

I think your zip corrupted, it happens because windows handle some files/characters differently than linux. Using the first command you’ll optimize your zip file for linux. Then using the second command unzip it. This solution should fix your problem.

zip -FF 210211.zip --out 210211-2.zip -fz

unzip 210211-2.zip
  • 1
    Should the `file` argument actually be there? It isn't in the answer you link to. Also, please explain what these commands do and whether you think it's feasible to run them on a 19 GB Zip archive. If you can show an alternative solution that doesn't rely on saving a temporary 19 GB file (piping from `zip` to `unzip` maybe, somehow; I'm not familiar with these Windows tools), that would be better. – Kusalananda Feb 13 '21 at 20:18
  • 1
    I'd like to avoid creating another 20GB file if possible, but will try this if no other alternatives come up. Would also be nice if the commands were explained. – holy_schmitt Feb 13 '21 at 20:27
  • @Kusalananda took care of that. –  Feb 14 '21 at 04:45
  • This trick didn't work. Trying to unzip the newly zipped file (using FF) gives fatal error: read failure while seeking for End-of-centdir-64 signature. – holy_schmitt Feb 15 '21 at 22:09
  • this actually worked for me. thanks! – But those new buttons though.. May 20 '22 at 17:11
  • 1
    It's worth noting that the `-FF` flag may "fix" things but the resulting zip may have missing data. The `-F` flag will preserve data but may still throw errors. Source: `unzip --help` – Speeddymon Jul 08 '22 at 19:44