• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Standard OS X Compression format
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Follow-Ups:
    • Re: Standard OS X Compression format
      • From: Markus Hitter <email@hidden>
References: 
 >Re: Standard OS X Compression format (From: Markus Hitter <email@hidden>)

  • Prev by Date: Memory Error -NSRTFReader?
  • Next by Date: Re: handing shutdown
  • Previous by thread: Re: Standard OS X Compression format
  • Next by thread: Re: Standard OS X Compression format
  • Index(es):
    • Date
    • Thread