Re: File types [was: Re: wide characters and i18n]

[Giles Lean <giles.lean%pobox.com@localhost>]

der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> So, tell me: besides the name, what is the difference between an
> extended attribute and an entry in the resource fork?  In particular,
> what makes the former good and the latter bad?

Bloody little.  (And bloody history. :-)

Resource forks have been decreed to be a Bad Thing: they
stored data, and developers are now strongly encouraged by
Apple to stop using them mainly due to difficulties
transferring files with foreign systems.

The preferred solution now is to put the "resource" data
(whatever it is -- icons, fonts, ...) into their own files.

Extended attributes (aka xattrs) are mainly intended for
metadata (although I can't find a clear statement about this
from Apple) but as the OS X manual page for setxattr(2) makes
clear extended attributes *subsume* resource forks, so perhaps
that "bloody little" difference is really no difference at
all, technically, but merely one of focus and intended use:

Extract of setxattr(2) manual page from OS X 10.6.4 (Snow Leopard):

"Extended attributes extend the basic attributes associated
 with files and directories in the file system.  They are
 stored as name:data pairs associated with file system objects
 (files, directories, symlinks, etc).

 setxattr() associates name and data together as an attribute of path.

 An extended attribute's name is a simple NULL-terminated
 UTF-8 string.  Value is a pointer to a data buffer of size
 bytes containing textual or binary data to be associated with
 the extended attribute.  Position specifies the offset within
 the extended attribute.  In the current implementation, only
 the resource fork extended attribute makes use of this
 argument.  For all others, position is reserved and should be
 set to zero."

And no, I can't find advice from Apple on when to use them or
what for. :-(  I notice browsers record which files have been
downloaded from the Internet and pop up a warning when I open
them the first time; that's certainly the most common usage I
see.

All that said, I do see an increasing need to add metadata to
files, however unfortunate the damage to the ideal of files as
"a bag of bytes" is:

o text files: character set encoding

o non-text files: preferred application (given a point-'n'-click
  GUI that tries to do the Right Thing when a data file is double
  clicked: without meta-data we're back to file extensions or
  magic numbers and a system wide (or at least user wide)
  default.

  As always seems to happen, there are odd files which will
  open in one application but not another even when they
  _should_ work in both; being able to tag "open this one in
  application XYZ instead of my normal ABC" is useful.  But
  again, only when double clicking on a data file: from within
  an application, File->Open overrides, naturally.

As a Unix user from long enough ago that my beard (if I had
one) would be gray (not that I have the moral authority of an
old "graybeard" ;-), I'd prefer to see imaginative use made of
existing APIs rather than new ones introduced.

If you have to change applications for them to understand meta
data anyway, is it any harder to teach an editor when it's
offered a directory to see if that directory contains one text
file and aother file giving the text file's encoding (assuming
reasonable conventions about naming) than it is to make it use
a totally new API to recover the meta data?

I think xattrs on OS X are here to stay (whether I like 'em or
not).  I can /hope/ that some consistency will develop across
platforms about what meta data means (particularly with respect
to character sets) as that would help translation from one
file system to another.

As to what NetBSD should do, having put in my 2c, I offer no
advice.  (Frankly, it's not my place: my contributions to
NetBSD have been very minor, in part because I worked for many
years with a Unix vendor on their source code while the silly
SCO litigation raged; even the appearance of conflict of
interest was well worth avoiding in both my employer's and
NetBSD's iterests. Oh, and mine!)

Giles