Mac Forks

Skip to first unread message

Tiran Dagan

Dec 18, 1997, 3:00:00 AM12/18/97

I am trying to address a problem I haven't seen mentioned anywhere.

I have a Mac connected to a UAM volume. An application on the mac saves a
file, and places into the resource fork 6 fields: PatientName, ServiceType,

The aplication is a siemens gamma camera acquisition system. The file is a
PICT file called Savescreen.

If I run ResEdit on the Mac, and view the file sitting on the NT volume, I
can see the resources.

The question is: Where are these resources stored? Is it part of the file,
ordoes NT store it in the directory structure? How do I access the
information programmatically, easily?

I haven't found any source code for this, on the PC side. I would
appreciate your help!

Tiran Dagan
Tel (800) 522-6299

Eddie Bowers

Dec 19, 1997, 3:00:00 AM12/19/97

The Macintosh resource fork for a file is kept in the same file as the data
fork , but in a second
stream called:AFP_Resource. Directories do not have a resource fork. If a
file has no
resource fork, the :AFP_Resource stream is not created on the file. Exact
case of this stream name must be used if creating this stream.

Finder Comments
The Macintosh Finder comments for a file or directory (as viewed from the
Finder File-Get Info) is stored in a stream called :Comments. If a file or
directory has no Finder comments, the :Comments stream is not created. The
text stored in the stream must be Unicode. Exact case of this stream name
must be used if creating this stream.

Finder Info, ProDOS Info and Backup Time

Other Macintosh information (such as Macintosh Finder type and creator) and
SFM internal information is stored in a stream called :AFP_AfpInfo. Both
files and directories have this 60-byte stream added the first time the SFM
AFP server discovers its existence or creates the file/dir on behalf of a
Macintosh client. The format of the :AFP_AfpInfo stream is:

typedef struct _AfpInfo
DWORD afpi_Signature; // Must be *(PDWORD)"AFP"
LONG afpi_Version; // Must be 0x00010000
DWORD afpi_Reserved1;
DWORD afpi_BackupTime; // Backup time for the file/dir
FINDERINFO afpi_FinderInfo; // Finder Info (32 bytes)
PRODOSINFO afpi_ProDosInfo; // ProDos Info (6 bytes) #
BYTE afpi_Reserved2[6];

Creating the AFP_AfpInfo stream on a file or directory behind the back of
the SFM AFP server is strongly discouraged. The preferred method of dealing
with this stream is to allow the SFM file server to create the stream
itself. This happens automatically the first time a file is discovered by
the server, either when the server is started (and a SFM volume exists
which contains the file/dir), a SFM volume is created which contains the
file/dir, or by a directory change notification of FILE_ACTION_ADDED on a
live server volume. The data from this stream can then be read, the stream
truncated, the modifiable information changed, and the data written back
out to the stream (exactly as it was read in, except for modifications to
FinderInfo, ProDosInfo or Backup time). The only way the SFM server picks
up changes to the FinderInfo of a file while it is running is if the stream
size changes. This is accomplished by truncating the stream after reading
it but before writing it back. The stream must be 60 bytes in length as per
the structure defined above, and must have the expected signature and
version as described below, or else the data is considered corrupted by the
server and the file reverts to the creator and type appropriate to the SFM
filename extension mappings currently configured. To ensure consistent
access to this stream by the server and a Windows NT application that may
be writing to it behind its back, make sure no Macintosh clients are
accessing the file at the same time it is being tampered with from the
Windows NT side application, and make sure the data is written back exactly
as read, except for the allowed modifications.

If it is necessary for the Windows NT application to create the
:AFP_AfpInfo stream, the case of the stream name must be exactly as shown
here, the reserved fields must be zeroed, and the modifiable fields of the
structure should be initialized according to the following rules:

afpi_Signature - Must be 0x00504641 (*(PDWORD)"AFP").
afpi_Version - Must be 0x00010000.
afpi_Reserved1 - Must be 0 if creating the stream.
afpi_BackupTime - Should be 0x80000000 (never been backed up) if
creating the file.
afpi_FinderInfo - Any information not set should be zero. When setting
FinderInfo type or creator, keep ProDOS information
in sync appropriately.
afpi_ProDosInfo - Any information not set should be zero.

Default for files should be:

afpi_ProDosInfo.pd_FileType[0] = PRODOS_TYPE_FILE;

Default for directories should be:

afpi_ProDosInfo.pd_FileType[0] = PRODOS_TYPE_DIR;
afpi_ProDosInfo.pd_AuxType[1] = PRODOS_AUX_DIR;

When setting ProDosInfo on a file, keep FinderInfo type and creator in sync

afpi_Reserved2 - Must be 0 if creating the stream.

FINDERINFO and PRODOSINFO have the following structure:

// Mac Finder Information layout

// see pg. 9-37 of Inside Macintosh vol. 6
#define FINDER_FLAG_INVISIBLE 0x40 // fd_Attr1
#define FINDER_FLAG_SET 0x01 // fd_Attr1
#define FINDER_FLAG_HAS_CUSTOM_ICON 0x04 // fd_Attr1

typedef struct
BYTE fd_Type[4];
BYTE fd_Creator[4];
BYTE fd_Attr1; // Bits 8-15
BYTE fd_Attr2; // Bits 0-7
BYTE fd_Location[4];
BYTE fd_FDWindow[2];
BYTE fd_OtherStuff[16];

// Apple-II (ProDOS) information.

// default values for newly discovered items
#define PRODOS_TYPE_FILE 0x04 // corresponds to finder fdType TEXT'
#define PRODOS_TYPE_DIR 0x0F
#define PRODOS_AUX_DIR 0x02 // actually 0x0200

// some other finder fdType to prodos FileType mapping values

typedef struct
BYTE pd_FileType[2];
BYTE pd_AuxType[4];


Tiran Dagan wrote in message <01bd0c13$a83269b0$0200a8c0@manager>...

Reply all
Reply to author
0 new messages