What causes zip to use error codes that don't match the man page?

Question

Level 1

0 points

What causes zip to use error codes that don't match the man page?

Hi All,

I have a script that runs a zip command similar to the following:

/usr/bin/zip -9oTr -lf "/var/folders/kv/pq58fps946n9tbkpc9wjsgy40000gn/T/Backup_zip.log" "/Volumes/LaCie Backup/System HD:Folder/Main Catalog/Backups/Config-20130108_141353.zip" ./Preferences/com.adobe.*.plist "./Application Support/Adobe"> "/var/folders/kv/pq58fps946n9tbkpc9wjsgy40000gn/T-2" 2>&1

As you can see it uses the standard zip distributed with the OS.

Sometimes the zip command returns values that are not possible, at least according to the man page. zip can return values of 0 to 19. Because I am using the test argument I also might receive unzip return values, which can be between 0 to 82.

In a recent example an error code of 4608 was returned, which is no where near the range of return code values that should be possible. The log file did include some errors such as follows:

zip warning: name not matched: ./Preferences/com.Adobe.Common.plist

zip warning: Permission denied

zip warning: could not open for reading: Application Support/Adobe/Lightroom/Modules/AutopanoGiga3.lrplugin/Contents/MacOS/Lightroom Plugin_mac

zip warning: Not all files were readable

So obviously there were some issues but I'm hoping to decipher the error code to get a deeper understanding of what is going on here. And to allow me to update the script to respond appropriately when errors occur.

Can someone please suggest the best way to interpret these "out of range" return codes from the zip command? I'd prefer to sitck with the default zip distribution because this isn't the only system I use the script on.

Thanks,

Matt

MacBook Air, Mac OS X (10.7.4)

Posted on Jan 9, 2013 10:32 PM

Reply

Answer 1

Best reply

MrHoffman

Community+ 2024

Level 10

116,595 points

Jan 10, 2013 8:17 AM in response to DawMatt

Pull the source code from Info-Zip.org and have a look. (It's no small tool, and figuring out where this is percolating up lilkely won't be easy.) I'd guess that the 4608 value is some random "garbage" value that's being returned for some error path that's been triggered; that code is not a valid macerrors.h error value, either.

Philosophically, this is a losing battle. Errors get added, bugs get introduced, and bugs get slain, and every so often a lower-level error percolates up somewhere. Capture the specific errors you need to deal with, and get out for the rest. If it's a zero, you're good. Otherwise, I'd suggest "Leaving, what a good idea" – print appropriate diagnostics and exit the script.

FWIW, you might get some better control by adding the files to the zip archive one at a time. Dumping out the ls -ale@ output for each file might also help when debugging, if something goes sideways.

Reply

Answer 2

DawMatt Author

Level 1

0 points

Jan 11, 2013 5:04 AM in response to MrHoffman

Thanks for the response. I'll download the source and see if it sheds any light on the situation, and I'll also try to make the script less dependent upon the return codes.

Reply

Answer 3

Jan 11, 2013 12:48 PM in response to DawMatt

BTW: the Info-Zip maintainers I've dealt with over the years have been responsive. Package up a detailed bug report (and preferably a reproducer), and send it along.

Reply