This is a warning as well as a hint. Control-clicking on a file or folder brings up a contextual menu that includes the option to
Create archive of "xxx". The created archive file is a zip file that can be unzipped with
/usr/bin/unzip. So, one would think that OS X is using /usr/bin/zip to create the archive. But that isn't so. It seems that OS X creates the zip file using code internal to Finder. It seems (from output of
ps or
top) not to be using /usr/bin/zip. Now the warning: /usr/bin/zip is broken on HFS+ file systems. It is broken in two ways:
- By default, it does not preserve the resource fork of files that it archives.There seems to be no way to force it to preserve resource forks. (Has anyone found a way?)
- Its behaviour does not correspond to its man page: /usr/share/man/man1/zip.1
Those (like me) who want to automate backups of their system using command line tools should perhaps use /usr/bin/tar. The
tar utility now (as of OS X 10.4.8 and perhaps earlier) preserves resource forks. It stores the resource fork of
foo as
._foo, and then recombines the data and resource forks when untarring to an HFS+ volume. To archive and compress a folder
foo and all of its subfolders, one can do:
$ /usr/bin/tar cjvf foo.tbz foo
And to restore it, one can do:
/usr/bin/tar xjvf foo.tbz
This seems to preserve the resource forks correctly. For other methods, maybe see the hint
Easily create HFS-aware PKZIP and unix archives.