Silverware and MacOS forks (was Re: X11R4 from wustl "can't ioctl())

[Robert Minich]

me:
|  This is not particularly helpful for the original problem, but I didn't want
|anyone thinking "Hmm, a MacOS file is a really screwed up thing." There are
|TWO (not three) forks. The "info fork" is actually info on the file as a whole,
|kept by the file system, like last modification date, name of the file, etc.
|(By Richard's explanation, one could call a UNIX file two-forked!)

rmtodd at servalan.uucp (Richard Todd): 
|   Uh, doesn't it also contain the type/creator information?

Yes, the FS keeps track of those, too. That's "etc." ;-)

|   BTW, although I can't seem to find any trace of it in the Apple docs I
| have, I didn't invent the term "info fork" to refer to that little chunk of
| information; I seem to recall it being used in the CAP docs, and if I remember
| correctly, on AUFS (the Appleshare-on-Unix server), the "info fork" is
| indeed stored as a separate file, as is the resource fork.  

  OK, you may have desert tonight. For AUFS, one certainly does have an info
file but only because there is no other place to put the info. I imagine I'd do
something similar to support permissions for UNIX on a MacOS server. (Probably
using the resource fork!) Still, there is no "info" fork of a Mac file. It's
all kept track of by the file system which maintains a couple files of its own:
the Extents Tree file and the Catalog Tree file. The extents tree keeps track
of the blocks which belong to a file (identified by a unique file ID). The
catalog tree has all the goodies like file names, creator/type, last mod
date, file ID, etc. I think I'll call any part of a file that can grow to an
arbitrary length a fork. The info for a MacOS file doesn't grow. It just
changes. The data and resource forks can expand and contract as need be (and
disk permits.)

|   And yes, to those of use used to Unix files which only have a byte stream
| and a few bits of file modes, mod times, etc., MacOS files *are* really 
| weird things :-).  

I bet. Of course to me, /dev is a pretty darn bizarre concept...

SIDE NOTE:
  I recall a long while back someone getting annoyed with trying to incremental
backups of AUFS files. Specifically, some of the forks would go untouched for
a while (say, the resource fork) and wouldn't be backed up while others (say,
the data fork) would change and thus would be backuped up. (Perhaps it was
even more pernicious, like having a fork migrate to a tap archive!) Would it
be simple enough to do a "touch" on each file whenever one fork was altered?
It seems like a 15 line modification to me. Has anyone done this?
-- 
|_    /| | Robert Minich            |
|\'o.O'  | Oklahoma State University| A fanatic is one who sticks to 
|=(___)= | minich at d.cs.okstate.edu  | his guns -- whether they are 
|   U    | - Ackphtth               | loaded or not.