Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Marcel Weiher <email@hidden>
- Date: Wed, 28 Nov 2001 16:14:38 +0100
On Friday, November 23, 2001, at 02:32 PM, Markus Hitter wrote:
Instead of writing long mails to the list, you could start improving
one of the open sourced tar's, like gnutar.
[Agreement]
Perhaps you want to begin adding an "Apple" parameter flag which is set
by default to "on" on all Resource fork aware OS's (OS X, Darwin) and
off on others.
With this flag set, tar would automatically include all ._file
counterparts on UFS, NFS and similar filesystems. Would probably not
too difficult to implement and a real advantage when archiving single
files on UFS.
I volunteer for this effort...done!
And the result is: gnutar!
Seriously, I don't understand what all the fuss is about. The special
representation that Carbon (and thus the finder) uses for representing
resource forks and finder-info on non-forked file-systems is already
fully supported by existing backup tools. This information is stored in
plain files with the '._' prefix. These 'special' names are special
only to Carbon. I cannot stress this enough because this seems to be at
the root of some of the misunderstandings floating around: the
special '._' files are special only to Carbon, all the lower levels of
the OS (Darwin/BSD-level) treat them as ordinary files. The file-system
and other tools do not care that these files are special to Carbon and
treats them just like nay other ordinary file. Therefore, gnutar will
archive and restore these files perfectly fine.
Please try it out to see for yourself.
The fact that these filenames aren't at all special to anything but
Carbon is the very reason why using this convention is not backwards
compatible.
Next you could add some code to pick up resource forks on HFS into this
._file.
As a last step, unpacking ._files into resource forks could be done.
It seems to me that this would be a perfectly fine separate utility. It
could also be turned into an option of an archiver, but that would be
feature-bloat. I am sure that mainframe users would also consider it
useful to have their files converted to/from ASCII/EBCDIC during
archiving...
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.