cck@CUNIXC.COLUMBIA.EDU (Charlie C. Kim) (07/29/87)
Here's a message that defines the scheme currently used by Aufs a bit
more rigidly along with some future work we're thinking of.
Charlie C. Kim
User Services
Columbia University
DRAFT: July 29, 1987
FILE STORAGE:
------------
For a particular file in a particular directory:
Macintosh file data fork: stored as a file in the directory.
Macintosh file resource fork: stored as a file in directory in
subdirectory .resource
Macintosh file information: stored as a file in directory in
subdirectory .finderinfo
Note: the subdirectories .resource and .finderinfo are used only if
the exist. Aufs will only create them if it receives a create
directory command from the Mac.
The file name used in the above three cases is mapped from Unix to
Macintosh file names as:
Mac to Unix
if (char is ascii and not control and is printable and
is not "/") then
leave as is
else
replace with ":" followed by two hexidecimal
digits that is a direct encoding of the binary
value of the char
Unix to Mac:
if (":" followed by two hex digits) then
replace with binary value of hex digits
if (":" not followed by two hex digits) then
replace ":" with "|".
DESKTOP INFORMATION
-------------------
Stored on a per volume basis. Two non-file specific parts are
application creator to application mappings stored in .ADeskTop and
icon database stored in .IDeskTop. Both these files appear in the
root directory of the volume.
The format of the .ADeskTop and .IDeskTop files is documented in
"CURRENT FILE FORMATS".
FILE INFORMATION
-----------------
Stored on a per file basis as noted in "FILE STORAGE". If a file has
no .finderinfo file associated with it, then following defaults are
used:
finderinfo (32 bytes)
type: TEXT [first four bytes]
creator: unix [second four bytes]
rest is set to zeros
file attributes
locked (0x0020)
comment:
"This is a Unix\252 created file." (\252 is the tm sign)
The format of the .finderinfo files is documented in "CURRENT FILE
FORMATS".
END OF LINE MAPPING
-------------------
If a file has creator "unix" and type "TEXT", then lf's are mapped to
cr's on reads and vice versa on writes. Note: anytime "line at a
time" reads with "cr" (mac line terminator) as the end of line
terminator are done, then both "cr" and "lf" are used as end of line
terminators regardless of the file creator and type.
CURRENT FILE FORMATS
--------------------
In the following, "bit.x" defines a type of x bits. "str" means an
ascii string (256 character ascii set) terminated by a null. The
formats are defined below in the formats section.
.ADeskTop format:
The .ADeskTop file contains an array of the following structure:
bit.32 afr_magic; /* magic number for check */
bit.8 a_FCreator[4]; /* creator of application */
bit.8 a_ATag[4]; /* user tag information */
bit.32 afr_pdirlen; /* length of parent directory name */
bit.32 afr_fnamlen; /* length of application name */
str pdir[afr_pdirlen]; /* path to directory holding */
/* appl. relative to volume root */
str file[afr_fnamlen]; /* file name */
The file names are stored are the unix file names. Note: the
directory path is relative to the volume root directory. The magic
number is a consistency check and is currently: AFR_MAGIC (8107+8556).
.IDeskTop format
The .IDeskTop file contains an array of the following structure:
bit.32 ifr_magic; /* the magic check */
bit.8 i_FCreator[4]; /* file's creator type */
bit.8 i_FType[4]; /* file's type */
bit.8 i_IType; /* icon type */
bit.8 i_ITag[4]; /* user bytes */
bit.32 i_bmsize; /* size of the icon bitmap */
bit.8 i_icon[i_bmsize]; /* icon */
The magic number is a consistency check and is currently: IFR_MAGIC
(8107+5750).
The .finderinfo files contain the following information:
bit.8 fi_fndr[32]; /* finder info */
bit.16 fi_attr; /* attributes */
bit.8 fi_comln; /* length of comment */
bit.8 fi_comnt[200]; /* comment string */
FUTURE FILE INFORMATION
-----------------------
The following is a proposal under review. I haven't consulted Bill on
this yet, so we may end up changing this.
The current .finderinfo file format will probably change. First, in
recognition of the fact that the .finderinfo is really more "fileinfo"
than just finder information, the subdirectory name will change to
".fileinfo". (Also implicitly gives the .finderinfo file a version).
The format of the .fileinfo file will be:
bit.8 VERSION
* initially 0x10. First 4 bits indication version, second 4
bits indicate revision. Revision bits are updated if BITMAP
(below) has additional items added. Version bits change if
drastic change is made
bit.16 BITMAP
* BITMAP contents indicate if a particular information is
valid:
0x1 - 32 bytes of Finder information
0x2 - bit.16 of file attributes (AFP)
0x4 - comment (comment length + comment)
0x8 - short file name (MSDOS)
0x10 - Macintosh file name (Sys V) (Stored untranslated)
* Space is reserved for the following items regardless of bitmap.(1)
bit.8 fi_fndr[32]; /* finder info */
bit.16 fi_attr; /* attributes */
bit.8 fi_comln; /* length of comment */
bit.8 fi_comnt[200]; /* comment string */
bit.8 fi_shortfilename[12]; /* ms dos file name */
bit.8 fi_macfilename[32]; /* macintosh file name */
(1) We really mean that unused items take up space - this makes
reading/writing easier since you don't have to do two reads or do any
packing or unpacking. It doesn't make a difference in terms of actual
space used unless bigger than unix file system block size anyway, so
if we keep it under 512 bytes (bsd fast file system usually has larger
block sizes), then it won't really waste space under Unix.