zip -df

While I can see the -df option in the man page, when I let zip tell me its options

zip
Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
Zip 2.32 (June 19th 2006). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
 The default action is to add or replace zipfile entries from list, which
 can include the special name - to compress standard input.
 If zipfile and list are omitted, zip compresses stdin to stdout.
 -f freshen: only changed files -u update: only changed or new files
 -d delete entries in zipfile -m move into zipfile (delete files)
 -r recurse into directories -j junk (don't record) directory names
 -0 store only -l convert LF to CR LF (-ll CR LF to LF)
 -1 compress faster -9 compress better
 -q quiet operation -v verbose operation/print version info
 -c add one-line comments -z add zipfile comment
 -@ read names from stdin -o make zipfile as old as latest entry
 -x exclude the following names -i include only the following names
 -F fix zipfile (-FF try harder) -D do not add directory entries
 -A adjust self-extracting exe -J junk zipfile prefix (unzipsfx)
 -T test zipfile integrity -X eXclude eXtra file attributes
 -y store symbolic links as the link instead of the referenced file
 -R PKZIP recursion (see manual)
 -e encrypt -n don't compress these suffixes

it does not list -df.

Also when I checked out zip on my Tiger system, I get the same behavior. The man page said there was -df, but the command itself gave the same error you are reporting.

So I do not know how long ago you last used zip -df, but it must have been before Tiger.

Also I did a zip experiment using a file I know has a resource fork (an old Mac OS X Classic executable), and the unzipped file did not have the resource fork.

Before zip:

$ ls -l Fred Fred/rsrc
-rwxrwxrwx 1 harris harris 346991 Dec 4 1997 Fred
-rwxrwxrwx 1 harris harris 348308 Dec 4 1997 Fred/rsrc

After unzip:

$ ls -l Fred Fred/rsrc
-rwxrwxrwx 1 harris wheel 346991 Dec 4 1997 Fred
-rwxrwxrwx 1 harris wheel 0 Dec 4 1997 Fred/rsrc

So it would seem to me that zip is not saving the resource fork anyway.

I think the consensus with that odd ' man' page entry is that it refers to the old MacOS, not "OS X"...
eg.
http://mirrors.ibiblio.org/pub/mirrors/CTAN/tools/zip/info-zip/MACOS/00README.ma czip

Note that that same ' man' page includes instruction for use with other operating systems - "Amiga", "OS/2", etc - it may be a current ' man' page, but that doesn't necessarily mean that everything pertains to "OS X". Also note that the same bizarre grammar that occurs regarding the ' -df' flag in the "19 June 2006" ' man' page also occurs in the "maczip" documentation. Nobody calls OS X "MacOS" - mention of the ' -df' flag very likely is a carry-over from the older software, referring to the latest version of ' zip' floating around for the old Mac OS.

For what it's worth it has been my experience that the ' -df' flag has never worked for "zip" in OS X, at least since Panther. Try searching the web, and I think you will find similar questions asked about that particular option.

Ok, but my point was just that there probably isn't any reason to put too much stock in what the ' man' page says about ' -df' as it most likely is not relevant to "OS X".

As "Bob Harris" already pointed out, ' zip' in "OS X" doesn't appear to be resource fork aware as it is. Recompiling with an option to ignore resource forks would be somewhat redundant.

Edit: This is from "Tiger", but note that it mentions archivers such as ' tar', ' rsync', ' gzip', ' bzip2', and ' cpio' being resource fork aware, with plain old ' zip' conspicuously absent.
http://images.apple.com/macosx/pdf/MacOSXUNIXTB.pdf

macmartin wrote:
I had complaints from a Windows User about files with the same name as the original files but starting with ._ so I first thought of resource forks.

You're right, that would be the resource forks. For what it's worth, if you compress files in the Finder, using the the "Compress..." menu item from the "File" menu, you will get the resource forks. But it looks like the command line zip should ignore them. I think this is because the Finder is using a different compression utility, not the regular old zip.

Here's a little piece of what I get if I compress with the Finder (Carbon app):

$ unzip -l /Users/username/Desktop/Calendar.zip 
Archive: /Users/username/Desktop/Calendar.zip
 Length Date Time Name
 -------- ---- ---- ----
 0 10-15-02 16:56 Calendar.app/
 6148 10-15-02 16:56 Calendar.app/.DS_Store
 0 02-25-09 19:03 __MACOSX/
 0 02-25-09 19:03 __MACOSX/Calendar.app/
 82 10-15-02 16:56 _MACOSX/Calendar.app/._.DSStore
 0 10-15-02 16:57 Calendar.app/Contents/
 6148 10-15-02 16:57 Calendar.app/Contents/.DS_Store
 0 02-25-09 19:03 __MACOSX/Calendar.app/Contents/
 82 10-15-02 16:57 _MACOSX/Calendar.app/Contents/._.DSStore
 1069 10-15-02 16:50 Calendar.app/Contents/Info.plist

Which includes resource forks. But if I compress the same app with command line zip ( zip -r test /path/to/app), I get this:

unzip -l test.zip
Archive: test.zip
 Length Date Time Name
 -------- ---- ---- ----
 0 10-15-02 16:56 Calendar.app/
 6148 10-15-02 16:56 Calendar.app/.DS_Store
 0 10-15-02 16:57 Calendar.app/Contents/
 6148 10-15-02 16:57 Calendar.app/Contents/.DS_Store
 1069 10-15-02 16:50 Calendar.app/Contents/Info.plist
 0 10-15-02 16:57 Calendar.app/Contents/MacOS/
 6148 10-15-02 16:57 Calendar.app/Contents/MacOS/.DS_Store
 51588 10-15-02 16:50 Calendar.app/Contents/MacOS/Calendar
 8 10-15-02 16:50 Calendar.app/Contents/PkgInfo
 0 10-15-02 16:50 Calendar.app/Contents/Resources/

charlie