On 2017-12-16 2:24 PM, David Empson wrote:
Alan Baker wrote:

On 2017-12-14 4:31 PM, Your Name wrote:
Many people confuse the Finder's information as being part of the
resource fork, but they are different. The Finder's information is not
stored inside the file at all.

Would you care to explain, then, how the Finder knows what information
to apply to which file?

The Finder Information (including type and creator) is part of the
file's directory entry in the Catalog Tree on HFS/HFS+ volumes,
alongside other fields like the pointers to the data and resource forks,
creation date, modification date, etc.

Here is an example from the HFS+ technical note (have a hunt around the
net for "Technical Note TN1150 HFS Plus Volume Format" as Apple removed
it from publication a while ago - I kept a copy).

They might not make it easy to find, but:

https://developer.apple.com/legacy/library/technotes/tn/tn1150.html


For a normal file:

struct HFSPlusCatalogFile {
SInt16 recordType;
UInt16 flags;
UInt32 reserved1;
HFSCatalogNodeID fileID;
UInt32 createDate;
UInt32 contentModDate;
UInt32 attributeModDate;
UInt32 accessDate;
UInt32 backupDate;
HFSPlusBSDInfo permissions;
FileInfo userInfo;
ExtendedFileInfo finderInfo;
UInt32 textEncoding;
UInt32 reserved2;
HFSPlusForkData dataFork;
HFSPlusForkData resourceFork;
};

(The filename is stored elsewhere.)

The "Finder Information" traditionally (e.g. HFS) is actually two 16
byte records. HFS+ calls them "File Information" and "Extended File
Information":

struct FileInfo {
OSType fileType; /* The type of the file */
OSType fileCreator; /* The file's creator */
UInt16 finderFlags;
Point location; /* File's location in the folder. */
UInt16 reservedField;
};

struct ExtendedFileInfo {
SInt16 reserved1[4];
UInt16 extendedFinderFlags;
SInt16 reserved2;
SInt32 putAwayFolderID;
};

As can be seen from the HFSPlusCatalogFile structure, the Finder
information, data fork and resource fork are three separate structures
associated with a file: the Finder Information is fixed size while the
data and resource fork are structurally identcal at the file system
level.

For reference, here is the HFSPlusForkData for HFS+ (which is
significantly changed from HFS - see below):

struct HFSPlusForkData {
UInt64 logicalSize;
UInt32 clumpSize;
UInt32 totalBlocks;
HFSPlusExtentRecord extents;
};

typedef HFSPlusExtentDescriptor HFSPlusExtentRecord[8];

struct HFSPlusExtentDescriptor {
UInt32 startBlock;
UInt32 blockCount;
};



For comparison, here is the corresponding structure for a file in HFS
(from Inside Macintosh, extracted from a Pascal record definition):

cdrFilRec: {file record}
filFlags: SignedByte; {file flags}
filTyp: SignedByte; {file type}
filUsrWds: FInfo; {Finder information}
filFlNum: LongInt; {file ID}
filStBlk: Integer; {first alloc. blk. of data fork}
filLgLen: LongInt; {logical EOF of data fork}
filPyLen: LongInt; {physical EOF of data fork}
filRStBlk: Integer; {first alloc. blk. of resource fork}
filRLgLen: LongInt; {logical EOF of resource fork}
filRPyLen: LongInt; {physical EOF of resource fork}
filCrDat: LongInt; {date and time of creation}
filMdDat: LongInt; {date and time of last modification}
filBkDat: LongInt; {date and time of last backup}
filFndrInfo: FXInfo; {additional Finder information}
filClpSize: Integer; {file clump size}
filExtRec: ExtDataRec; {first data fork extent record}
filRExtRec: ExtDataRec; {first resource fork extent record}
filResrv: LongInt); {reserved}

The Finder and Extended Finder Information records:

TYPE FInfo =
RECORD
fdType: OSType; {file type}
fdCreator: OSType; {file creator}
fdFlags: Integer; {Finder flags}
fdLocation: Point; {file's location in window}
fdFldr: Integer; {directory that contains file}
END;

TYPE FXInfo =
RECORD
fdIconID: Integer; {icon ID}
fdUnused: ARRAY[1..3] OF Integer;
{unused but reserved 6 bytes}
fdScript: SignedByte; {script flag and code}
fdXFlags: SignedByte; {reserved}
fdComment: Integer; {comment ID}
fdPutAway: LongInt; {home directory ID}
END;


Interesting. Thanks!


I'd have to dig into even older references to find the MFS equivalent,
but I expect it had the first 16-byte Finder Information record without
the second 16-byte Extended Finder Information, given how HFS broke them
up into two records, and different APIs were used to access them.


When Mac files are stored on foreign file systems, the Mac-specific
infomration needs to be retained. Mac OS X does this by storing the data
fork as the "normally named" file, and everything else goes into an
auxiliary file named with a period and underscore as a prefix, e.g.

example.jpg
._example.jpg

This is an implementation of the AppleDouble standard. The second file
is structured to contain multiple records. It includes whichever
additional structures from the file need to be stored: exactly which
ones are present depends on their state in the orignal file.

If all the additional structures are empty or have default values, then
the "period underscore" file does not need to be created.

The presence of the "period underscore" file does NOT necessarily mean
the file has a resource fork - that is just one of the structures which
might be in the file. It could have non-default Finder Information (such
as a file type and creator) and nothing else.

Other data which goes in the "period underscore" file include additional
named forks beyond the data and resource forks (only a concept on HFS+),
such as extended attributes.


For further completeness:

Mac OS 9 and earlier used a similar AppleDouble structure to store Mac
files on foreign file systems, but they are arranged differently. Apple
chose to create a hidden directory called (misleadingly) RESOURCE.FRK
alongside the data fork file, and put the auxiliary file in there, with
the same name as the data fork file. As with Mac OS X, the file in the
RESOURCE.FRK directory _may_ include a resource fork, but it also
includes the Finder Informaiton.

This is probably where the false impression arose that the Finder
information was in the resource fork. It is actually separate, but
stored in the same file as the resource fork on a non-Mac file system.

Makes sense.


For even further completeness:

The name "AppleDouble" refers to the fact that the Apple file has been
split into two files for storage on a non-native file system (or for
transmission via a file transfer protocol). There is also an
"AppleSingle" format which combines the data fork and the other parts
into a single file, which can then be transferred via a foreign file
system or file transfer protocol and preserve all the Apple-native
content. I recall using AppleSingle format back when I was using the
Apple IIgs.

Other Mac-specific file encoding techniques were similar in concept to
AppleSingle, e.g. BinHex (which also did binary-to-ASCII encoding) and
MacBinary.

For even further further completeness:

Apple has two standards for the format of the data inside the resource
fork. The Macintosh and Apple IIgs have considerable differences in how
the data is structured, even in how individual resources are identified
(Mac: 4-char type stored as a 32-bit integer, 16-bit signed identifier;
IIgs: 16-bit unsigned type, 32-bit unsigned identifier).