X11R4 from wustl "can't ioctl(): Invalid argument"

[Richard Todd]

minich at d.cs.okstate.edu (Robert Minich) writes:

>by rmtodd at servalan.uucp (Richard Todd):

>  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!)

  Uh, doesn't it also contain the type/creator information?
  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.  

  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 :-).  

[good explanation of just what a resource fork is deleted.] 

>  I'm not aware of exactly what the definition of AppleSingle format is but
>I suspect it is just "MacBinary", a format developed to facilitate the use
>of BBS's for exchanging Mac files. The idea is that you wrap both forks
>and some of the system info about the file in one chunk and present that
>to your host as a single file. When downloading, a Mac comm program will
>recognize the MacBinary format and unwrap the file on it's way to the disk.

  Alas, no.  Though an AppleSingle file does have all the system info, the 
resource fork, and the data fork all wrapped up in one file, the format is
*not* the same as MacBinary.  Fortunately, the "fcnvt" program does allow 
conversion to/from MacBinary.