Unzip - Warning and Mapname

Question

I have a folder that I download from Dropbox using a shared link (not public link) and curl. It is downloaded as a zipped folder. I need to unzip this folder using unzip in a bash shell script. Whenever the folder is unzipped, I get the following errors:

warning:  stripped absolute path spec from /
mapname:  conversion of  failed

Just to make sure that it was not a weird issue with curl, I downloaded the folder directly from Dropbox and tried it again. I got the same error. All of the files and subdirectories appear, and there does not seem to be any problem with their integrity. Unzipping either folder with the GUI results in no error messages.

I ran unzip -l and noticed an odd first entry:

     Length   Method    Size  Ratio   Date   Time   CRC-32    Name
    --------  ------  ------- -----   ----   ----   ------    ----
           0  Defl:N        2   0%  01-23-14 19:38  00000000  /

I believe that it is this empty directory that is causing the issues. My question is, is there any way to ignore this empty directory or to suppress the error messages (I tried -qq with no luck)? Or, is there something that I am doing wrong/missing?

I have tested this on Mac OSX 10.9.1 and Ubuntu Linux (Version Unknown) with the same results.

EDIT: I also tested it with jar xf and it works fine without any errors. Running jar xvf shows that it created: /. I still think it is this empty, unnamed directory that is causing the issue, but I can't seem to get my syntax right so that unzip will ignore it. I would just use jar, but I need to be able to specify an output directory.

Answer 1

Trying to unzip from the command line a Dropbox autogenerated zip, I found this message too:

warning:  stripped absolute path spec from /
mapname:  conversion of  failed

I compared Dropbox's zip with a normal zip.

The difference was that, at the time of the unzipping, in the Dropbox's one appears in a first position a kind of file like /.

I just add the option -x / to the unzip command trying to exclude it, and it works for me.

Answer 2

In my opinion, the root issue is the archive, not your command.

By default, we store relative paths in a ZIP file. Example:

$ zip tmp.zip /home/mcoolive/*txt
adding: home/mcoolive/file1.txt (deflated 73%)
adding: home/mcoolive/file2.txt (deflated 76%)

By default, unzip recreates all files and subdirectories are recreated in the current directory.

In your case, the archive contains absolut paths. It's evil. So your client converts absolut paths into relative paths with a warning.