From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1740.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc1740.txt (limited to 'doc/rfc/rfc1740.txt') diff --git a/doc/rfc/rfc1740.txt b/doc/rfc/rfc1740.txt new file mode 100644 index 0000000..407792a --- /dev/null +++ b/doc/rfc/rfc1740.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group Patrik Faltstrom +Request for Comments: 1740 Royal Institute of Technology +Category: Standards Track Dave Crocker + Brandenburg Consulting + Erik E. Fair + Apple Computer Inc. + December 1994 + + + MIME Encapsulation of Macintosh files - MacMIME + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo describes the format to use when sending Apple Macintosh + files via MIME [BORE93]. The format is compatible with existing + mechanisms for distributing Macintosh files, while allowing non- + Macintosh systems access to data in standardized formats. + +2. Introduction + + Files on the Macintosh consists of two parts, called forks: + + Data fork: The actual data included in the file. The Data + fork is typically the only meaningful part of a + Macintosh file on a non-Macintosh computer system. + For example, if a Macintosh user wants to send a + file of data to a user on an IBM-PC, she would only + send the Data fork. + + Resource fork: Contains a collection of arbitrary attribute/value + pairs, including program segments, icon bitmaps, + and parametric values. + + Additional information regarding Macintosh files is stored by the + Finder in a hidden file, called the "Desktop Database". + + Because of the complications in storing different parts of a + Macintosh file in a non-Macintosh filesystem that only handles + consecutive data in one part, it is common to convert the Macintosh + file into some other format before transferring it over the network. + + + +Faltstrom, Crocker & Fair [Page 1] + +RFC 1740 MIME-based Mac files December 1994 + + + The two styles of use are [APPL90]: + + AppleSingle: Apple's standard format for encoding Macintosh files + as one byte stream. + AppleDouble: Similar to AppleSingle except that the Data fork is + separated from the Macintosh-specific parts by the + AppleDouble encoding. + + AppleDouble is the preferred format for a Macintosh file that is to + be included in an Internet mail message, because it provides + recipients with Macintosh computers the entire document, including + Icons and other Macintosh specific information, while other users + easily can extract the Data fork (the actual data) as it is separated + from the AppleDouble encoding. + +2. MIME format for Apple/Macintosh-specific file information + + 2a. APPLICATION/APPLEFILE + + MIME type-name: APPLICATION + MIME subtype name: APPLEFILE + Required parameters: none + Optional parameters: NAME, which must be a "value" as + defined in RFC-1521 [BORE93]. + Encoding considerations: The presence of binary data will + typically require use of + Content-Transfer-Encoding: BASE64 + Security considerations: See separate section in the document + Published specification: Apple-single & Apple-double [APPL90] + Rationale: Permits MIME-based transmission of + data with Apple/Macintosh specific + information, while allowing general + access to non-specific user data. + + 2b. MULTIPART/APPLEDOUBLE + + MIME type-name: MULTIPART + MIME subtype name: APPLEDOUBLE + Required parameters: none + Optional parameters: NAME, which must be a "value" as + defined in RFC-1521 [BORE93]. + Encoding considerations: none + Security considerations: See separate section in the document + Published specification: Apple-single & Apple-double [APPL90] + Rationale: Permits MIME-based transmission of + data with Apple/Macintosh specific + information, while allowing general + access to non-specific user data. + + + +Faltstrom, Crocker & Fair [Page 2] + +RFC 1740 MIME-based Mac files December 1994 + + + 2c. Detail specific to MIME-based usage + + Macintosh documents do not always need to be sent in a special + format. Those documents with well-known MIME types and + non-existent or trivial resource forks can be sent as regular + MIME body parts, without use of AppleSingle or AppleDouble. + + Documents which lack a data fork must be sent as AppleSingle. + + Unless there are strong reasons not to, all other documents + should normally be sent as AppleDouble. This includes documents + with non-trivial resource forks, and documents without + corresponding well-known MIME types. + + It may be valuable in some cases to allow the user to choose one + format over another, either because he disagrees with the + implementor's definition of "trivial" resource forks, or for + reasons of his own. + +3. AppleSingle + + An AppleSingle, version 2 file, is sent as one consecutive stream of + bytes. The format is described in [APPL90] with a brief summary in + Appendix A. The one and only part of the file is sent in an + application/applefile message. + + The first four bytes of an AppleSingle header are, in hexadecimal: + 00, 05, 16, 00. + + The AppleSingle file is binary data. Hence, it may be necessary to + perform a Content-Transfer-Encoding for transmission, depending on + the underlying email transport environment. The safest encoding is + Base64, since it permits transfer over the most restricted channels. + + Even though an AppleSingle file includes the original Macintosh + filename, it is recommended that a name parameter be included on the + Content-Type header to give the recipient a hint as to what file is + attached. The value of the name parameter must be a "value" as + defined by RFC-1521 [BORE93]. Note that this restricts the value to + seven-bit US-ASCII characters. + + 3a. AppleSingle example + + Content-Type: application/applefile; name="Computers-1/2-93" + + [The AppleSingle file goes here] + +4. AppleDouble + + + +Faltstrom, Crocker & Fair [Page 3] + +RFC 1740 MIME-based Mac files December 1994 + + + An AppleDouble, version 2, file is divided in two parts: + + Header: including the Macintosh resource fork and desktop + information and + Data fork: containing the Macintosh data fork. + + The AppleDouble format is described in [APPL90] with a brief summary + in Appendix B. + + The AppleDouble file itself is sent as a multipart/appledouble MIME + body-part, which may have only two sub-parts. The header is sent as + application/applefile and the data fork as whatever best describes + it. For example, is the data for is actually a GIF image, it should + be sent as image/gif. If no appropriate Content-Type has been + registered for the data type, it should be sent as an + application/octet-stream. + + The first four bytes of an AppleDouble header are, in hexadecimal: + 00, 05, 16, 07. + + The AppleDouble header is binary data. Hence, it may be necessary to + perform a Content-Transfer-Encoding for transmission, depending on + the underlying email transport environment. The safest encoding is + Base64, since it permits transfer over the most restrictive channels. + + Even though an AppleDouble file includes the original Macintosh + filename, it is recommended that a name parameter be included on the + Content-Type header of both the header and data parts of the + AppleDouble file to give the recipient a hint as to what file is + attached. The value of the name parameter must be a "value" as + defined by RFC-1521 [BORE93]. Note that this restricts the value to + seven-bit US-ASCII characters. + + 4a. AppleDouble example + + Content-Type: multipart/appledouble; boundary=mac-part + + --mac-part + Content-Type: application/applefile; name="My-new-car" + + [The AppleDouble header goes here] + + --mac-part + Content-Type: image/gif; + + [The data fork goes here] + + --mac-part-- + + + +Faltstrom, Crocker & Fair [Page 4] + +RFC 1740 MIME-based Mac files December 1994 + + +5. References + + BORE93 Borenstein N., and N. Freed, MIME (Multipurpose Internet + Mail Extensions): Mechanisms for Specifying and Describing + the Format of Internet Message Bodies, RFC 1521, Bellcore, + Innosoft, September 1993. + + APPL90 AppleSingle/AppleDouble Formats for Foreign Files + Developer's Note, Apple Computer, Inc., 1990 + +6. Security Considerations + + To the extent that application/applefile facilitates the transmission + of operating-system sensitive data, it may open a door for easier + relaxation of security rules than is intended either by the sender of + the administrator of the sender's system. + +7. Acknowledgements + + Thanks to all of the people on the ietf-822 list who have provided + much meaningful input for this document. Some of them must though be + remembered by name, because they have almost crushed my mailbox with + a very nice and interesting debate: + + Johan Berglund, Steve Dorner, David Gelhar, David Herron, Lee + Jones, Raymond Lau, Jamey Maze, John B. Melby, Jan Michael + Rynning, Rens Troost and Peter Svanberg. + +10. Authors' Addresses + + Patrik Faltstrom + Department of Numerical Analysis and Computing Science + Royal Institute of Technology + S-100 44 Stockholm + Sweden + + EMail: paf@nada.kth.se + + + Dave Crocker + Brandenburg Consulting + 675 Spruce Dr. + Sunnyvale, CA 94086 + + EMail: dcrocker@mordor.stanford.edu + + + Erik E. Fair + + + +Faltstrom, Crocker & Fair [Page 5] + +RFC 1740 MIME-based Mac files December 1994 + + + Engineering Computer Operations + Apple Computer Inc. + + EMail: fair@apple.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Faltstrom, Crocker & Fair [Page 6] + +RFC 1740 MIME-based Mac files December 1994 + + +Appendix A. The AppleSingle format + + In the AppleSingle format, a file's contents and attributes are + stored in a single file in the foreign file system. For example, + both forks of a Macintosh file, the Finder information, and an + associated comment are arranged in a single file with a simple + structure. + + An AppleSingle file consists of a header followed by one or more data + entries. The header consists of several fixed fields and a list of + entry descriptors, each pointing to a data entry. Each entry is + optional and may or may not appear in the file. + + AppleSingle file header: + + Field Length + + Magic number 4 bytes + Version number 4 bytes + Filler 16 bytes + Number of entries 2 bytes + + Entry descriptor for each entry: + + Entry ID 4 bytes + Offset 4 bytes + Length 4 bytes + + Byte ordering in the file fields follows MC68000 conventions, most + significant byte first. The fields in the header file follow the + conventions described in the following sections. + + Magic number + This field, modelled after the UNIX magic number feature, + specifies the file's format. Apple has defined the magic number + for the AppleSingle format as $00051600 or 0x00051600. + + Version number + This field denotes the version of AppleSingle format in the event + the format evolves (more fields may be added to the header). The + version described in this note is version $00020000 or + 0x00020000. + + Filler + This field is all zeros ($00 or 0x00). + + Number of entries + This field specifies how many different entries are included in + + + +Faltstrom, Crocker & Fair [Page 7] + +RFC 1740 MIME-based Mac files December 1994 + + + the file. It is an unsigned 16-bit number. If the number of + entries is any number other than 0, then that number of entry + descriptors immediately follows the number of entries field. + + Entry descriptors + + The entry descriptor is made up of the following three fields: + + Entry ID: an unsigned 32-bit number, defines what the entry is. + Entry IDs range from 1 to $FFFFFFFF. Entry ID 0 is + invalid. + Offset: an unsigned 32-bit number, shows the offset from the + beginning of the file to the beginning of the entry's + data. + Length: an unsigned 32-bit number, shows the length of the + data in bytes. The length can be 0. + + Predefined entry ID's + + Apple has defined a set of entry IDs and their values as follows: + + Data Fork 1 Data fork + Resource Fork 2 Resource fork + Real Name 3 File's name as created on home file + system + Comment 4 Standard Macintosh comment + Icon, B&W 5 Standard Macintosh black and white icon + Icon, Colour 6 Macintosh colour icon + File Dates Info 8 File creation date, modification date, + and so on + Finder Info 9 Standard Macintosh Finder information + Macintosh File Info 10 Macintosh file information, attributes + and so on + ProDOS File Info 11 ProDOS file information, attributes and + so on + MS-DOS File Info 12 MS-DOS file information, attributes and + so on + Short Name 13 AFP short name + AFP File Info 14 AFP file, information, attributes and so + on + Directory ID 15 AFP directory ID + + Apple reserves the range of entry IDs from 1 to $7FFFFFFF. The + rest of the range is available for applications to define their + own entries. Apple does not arbitrate the use of the rest of the + range. + +Appendix B. The AppleDouble format + + + +Faltstrom, Crocker & Fair [Page 8] + +RFC 1740 MIME-based Mac files December 1994 + + + The AppleDouble format uses two files to store data, resources and + attributes. The AppleDouble Data file contains the data fork and the + AppleDouble Header file contains the resource fork. + + The AppleDouble Data file contains the standard Macintosh data fork + with no additional header. The AppleDouble Header file has exactly + the same format as the AppleSingle file, except that it does not + contain a Data fork entry. The magic number in the AppleDouble + Header file differs from the magic number in the AppleSingle Header + file so that an application can tell whether it needs to look in + another file for the data fork. The magic number for the AppleDouble + format is $00051607 or 0x00051607. + + The entries in the AppleDouble Header file can appear in any order; + however, since the resource fork is the entry that is most commonly + extended (after the data fork), Apple recommends that the resource + fork entry to be placed last in the file. The data fork is easily + extended because it resides by itself in the AppleDouble Data file. + +Appendix C. applefile.h + + This is an example of a header file for the language C which can be + used when parsing the data in either an AppleSingle file or + AppleDouble header. + + The file is written by Lee Jones. Distribution is unlimited. + + /* applefile.h - Data structures used by AppleSingle/AppleDouble + * file format + * + * Written by Lee Jones, 22-Oct-1993 + * + * For definitive information, see "AppleSingle/AppleDouble + * Formats for Foreign Files Developer's Note"; Apple Computer + * Inc.; (c) 1990. + * + * Other details were added from: + * Inside Macintosh [old version], volumes II to VI, + * Apple include files supplied with Think C 5.0.1, + * Microsoft MS-DOS Programmer's Reference, version 5, and + * Microsoft C 6.00a's dos.h include file. + * + * I don't have ProDOS or AFP Server documentation so related + * entries may be a bit skimpy. + * + * Edit history: + * + * when who why + + + +Faltstrom, Crocker & Fair [Page 9] + +RFC 1740 MIME-based Mac files December 1994 + + + * --------- --- ------------------------------------------ + * 22-Oct-93 LMJ Pull together from Inside Macintosh, + * Developer's Note, etc + * 26-Oct-93 LMJ Finish writing first version and list + * references + * 06-Feb-94 EEF Very minor cleanup + */ + + /* Following items define machine specific size (for porting). */ + + typedef char xchar8; /* 8-bit field */ + typedef char schar8; /* signed 8-bit field */ + typedef unsigned char uchar8; /* unsigned 8-bit field */ + typedef short xint16; /* 16-bit field */ + typedef unsigned short uint16; /* unsigned 16-bit field */ + typedef long xint32; /* 32-bit field */ + typedef long sint32; /* signed 32-bit field */ + typedef unsigned long uint32; /* unsigned 32-bit field */ + + /* REMINDER: the Motorola 680x0 is a big-endian architecture! */ + + typedef uint32 OSType; /* 32 bit field */ + + /* In the QuickDraw coordinate plane, each coordinate is + * -32767..32767. Each point is at the intersection of a + * horizontal grid line and a vertical grid line. Horizontal + * coordinates increase from left to right. Vertical + * coordinates increase from top to bottom. This is the way + * both a TV screen and page of English text are scanned: + * from top left to bottom right. + */ + + struct Point /* spot in QuickDraw 2-D grid */ + { + xint16 v; /* vertical coordinate */ + xint16 h; /* horizontal coordinate */ + }; /* Point */ + + typedef struct Point Point; + + /* See older Inside Macintosh, Volume II page 84 or Volume IV + * page 104. + */ + + struct FInfo /* Finder information */ + { + OSType fdType; /* File type, 4 ASCII chars */ + OSType fdCreator; /* File's creator, 4 ASCII chars */ + + + +Faltstrom, Crocker & Fair [Page 10] + +RFC 1740 MIME-based Mac files December 1994 + + + uint16 fdFlags; /* Finder flag bits */ + Point fdLocation; /* file's location in folder */ + xint16 fdFldr; /* file 's folder (aka window) */ + }; /* FInfo */ + + typedef struct FInfo FInfo; + + /* + * Masks for finder flag bits (field fdFlags in struct + * FInfo). + */ + + #define F_fOnDesk 0x0001 /* file is on desktop (HFS only) */ + #define F_maskColor 0x000E /* color coding (3 bits) */ + /* 0x0010 /* reserved (System 7) */ + #define F_fSwitchLaunch 0x0020 /* reserved (System 7) */ + #define F_fShared 0x0040 /* appl available to multiple users */ + #define F_fNoINITs 0x0080 /* file contains no INIT resources */ + #define F_fBeenInited 0x0100 /* Finder has loaded bundle res. */ + /* 0x0200 /* reserved (System 7) */ + #define F_fCustomIcom 0x0400 /* file contains custom icon */ + #define F_fStationary 0x0800 /* file is a stationary pad */ + #define F_fNameLocked 0x1000 /* file can't be renamed by Finder */ + #define F_fHasBundle 0x2000 /* file has a bundle */ + #define F_fInvisible 0x4000 /* file's icon is invisible */ + #define F_fAlias 0x8000 /* file is an alias file (System 7) */ + + /* See older Inside Macintosh, Volume IV, page 105. + */ + + struct FXInfo /* Extended finder information */ + + { + xint16 fdIconID; /* icon ID number */ + xint16 fdUnused[3]; /* spare */ + schar8 fdScript; /* scrip flag and code */ + schar8 fdXFlags; /* reserved */ + xint16 fdComment; /* comment ID number */ + xint32 fdPutAway; /* home directory ID */ + }; /* FXInfo */ + + typedef struct FXInfo FXInfo; + + /* Pieces used by AppleSingle & AppleDouble (defined later). */ + + struct ASHeader /* header portion of AppleSingle */ + { + /* AppleSingle = 0x00051600; AppleDouble = 0x00051607 */ + + + +Faltstrom, Crocker & Fair [Page 11] + +RFC 1740 MIME-based Mac files December 1994 + + + uint32 magicNum; /* internal file type tag */ + uint32 versionNum; /* format version: 2 = 0x00020000 */ + uchar8 filler[16]; /* filler, currently all bits 0 */ + uint16 numEntries; /* number of entries which follow */ + }; /* ASHeader */ + + typedef struct ASHeader ASHeader; + + struct ASEntry /* one AppleSingle entry descriptor */ + { + uint32 entryID; /* entry type: see list, 0 invalid */ + uint32 entryOffset; /* offset, in octets, from beginning */ + /* of file to this entry's data */ + uint32 entryLength; /* length of data in octets */ + }; /* ASEntry */ + + typedef struct ASEntry ASEntry; + + /* Apple reserves the range of entry IDs from 1 to 0x7FFFFFFF. + * Entry ID 0 is invalid. The rest of the range is available + * for applications to define their own entry types. "Apple does + * not arbitrate the use of the rest of the range." + */ + + #define AS_DATA 1 /* data fork */ + #define AS_RESOURCE 2 /* resource fork */ + #define AS_REALNAME 3 /* File's name on home file system */ + #define AS_COMMENT 4 /* standard Mac comment */ + #define AS_ICONBW 5 /* Mac black & white icon */ + #define AS_ICONCOLOR 6 /* Mac color icon */ + /* 7 /* not used */ + #define AS_FILEDATES 8 /* file dates; create, modify, etc */ + #define AS_FINDERINFO 9 /* Mac Finder info & extended info */ + #define AS_MACINFO 10 /* Mac file info, attributes, etc */ + #define AS_PRODOSINFO 11 /* Pro-DOS file info, attrib., etc */ + #define AS_MSDOSINFO 12 /* MS-DOS file info, attributes, etc */ + #define AS_AFPNAME 13 /* Short name on AFP server */ + #define AS_AFPINFO 14 /* AFP file info, attrib., etc */ + + #define AS_AFPDIRID 15 /* AFP directory ID */ + + /* matrix of entry types and their usage: + * + * Macintosh Pro-DOS MS-DOS AFP server + * --------- ------- ------ ---------- + * 1 AS_DATA xxx xxx xxx xxx + * 2 AS_RESOURCE xxx xxx + * 3 AS_REALNAME xxx xxx xxx xxx + + + +Faltstrom, Crocker & Fair [Page 12] + +RFC 1740 MIME-based Mac files December 1994 + + + * + * 4 AS_COMMENT xxx + * 5 AS_ICONBW xxx + * 6 AS_ICONCOLOR xxx + * + * 8 AS_FILEDATES xxx xxx xxx xxx + * 9 AS_FINDERINFO xxx + * 10 AS_MACINFO xxx + * + * 11 AS_PRODOSINFO xxx + * 12 AS_MSDOSINFO xxx + * + * 13 AS_AFPNAME xxx + * 14 AS_AFPINFO xxx + * 15 AS_AFPDIRID xxx + */ + + /* entry ID 1, data fork of file - arbitrary length octet string */ + + /* entry ID 2, resource fork - arbitrary length opaque octet string; + * as created and managed by Mac O.S. resoure manager + */ + + /* entry ID 3, file's name as created on home file system - arbitrary + * length octet string; usually short, printable ASCII + */ + + /* entry ID 4, standard Macintosh comment - arbitrary length octet + * string; printable ASCII, claimed 200 chars or less + */ + + /* This is probably a simple duplicate of the 128 octet bitmap + * stored as the 'ICON' resource or the icon element from an 'ICN#' + * resource. + */ + + struct ASIconBW /* entry ID 5, standard Mac black and white icon */ + { + uint32 bitrow[32]; /* 32 rows of 32 1-bit pixels */ + }; /* ASIconBW */ + + typedef struct ASIconBW ASIconBW; + + /* entry ID 6, "standard" Macintosh color icon - several competing + * color icons are defined. Given the copyright dates + * of the Inside Macintosh volumes, the 'cicn' resource predominated + * when the AppleSingle Developer's Note was written (most probable + * candidate). See Inside Macintosh, Volume V, pages 64 & 80-81 for + + + +Faltstrom, Crocker & Fair [Page 13] + +RFC 1740 MIME-based Mac files December 1994 + + + * a description of 'cicn' resources. + * + * With System 7, Apple introduced icon families. They consist of: + * large (32x32) B&W icon, 1-bit/pixel, type 'ICN#', + * small (16x16) B&W icon, 1-bit/pixel, type 'ics#', + * large (32x32) color icon, 4-bits/pixel, type 'icl4', + * small (16x16) color icon, 4-bits/pixel, type 'ics4', + * large (32x32) color icon, 8-bits/pixel, type 'icl8', and + * small (16x16) color icon, 8-bits/pixel, type 'ics8'. + * If entry ID 6 is one of these, take your pick. See Inside + * Macintosh, Volume VI, pages 2-18 to 2-22 and 9-9 to 9-13, for + * descriptions. + */ + + /* entry ID 7, not used */ + + /* Times are stored as a "signed number of seconds before of after + * 12:00 a.m. (midnight), January 1, 2000 Greenwich Mean Time (GMT). + * Applications must convert to their native date and time + * conventions." Any unknown entries are set to 0x80000000 + * (earliest reasonable time). + */ + + struct ASFileDates /* entry ID 8, file dates info */ + { + sint32 create; /* file creation date/time */ + sint32 modify; /* last modification date/time */ + sint32 backup; /* last backup date/time */ + sint32 access; /* last access date/time */ + }; /* ASFileDates */ + + typedef struct ASFileDates ASFileDates; + + /* See older Inside Macintosh, Volume II, page 115 for + * PBGetFileInfo(), and Volume IV, page 155, for PBGetCatInfo(). + */ + + /* entry ID 9, Macintosh Finder info & extended info */ + struct ASFinderInfo + { + FInfo ioFlFndrInfo; /* PBGetFileInfo() or PBGetCatInfo() */ + FXInfo ioFlXFndrInfo; /* PBGetCatInfo() (HFS only) */ + }; /* ASFinderInfo */ + + typedef struct ASFinderInfo ASFinderInfo; + + struct ASMacInfo /* entry ID 10, Macintosh file information */ + { + + + +Faltstrom, Crocker & Fair [Page 14] + +RFC 1740 MIME-based Mac files December 1994 + + + uchar8 filler[3]; /* filler, currently all bits 0 */ + uchar8 ioFlAttrib; /* PBGetFileInfo() or PBGetCatInfo() */ + }; /* ASMacInfo */ + + typedef struct ASMacInfo ASMacInfo; + + #define AS_PROTECTED 0x0002 /* protected bit */ + #define AS_LOCKED 0x0001 /* locked bit */ + + /* NOTE: ProDOS-16 and GS/OS use entire fields. ProDOS-8 uses low + * order half of each item (low byte in access & filetype, low word + * in auxtype); remainder of each field should be zero filled. + */ + + struct ASProdosInfo /* entry ID 11, ProDOS file information */ + { + uint16 access; /* access word */ + uint16 filetype; /* file type of original file */ + uint32 auxtype; /* auxiliary type of the orig file */ + }; /* ASProDosInfo */ + + typedef struct ASProdosInfo ASProdosInfo; + + /* MS-DOS file attributes occupy 1 octet; since the Developer Note + * is unspecific, I've placed them in the low order portion of the + * field (based on example of other ASMacInfo & ASProdosInfo). + */ + + struct ASMsdosInfo /* entry ID 12, MS-DOS file information */ + { + uchar8 filler; /* filler, currently all bits 0 */ + uchar8 attr; /* _dos_getfileattr(), MS-DOS */ + /* interrupt 21h function 4300h */ + }; /* ASMsdosInfo */ + + typedef struct ASMsdosInfo ASMsdosInfo; + + #define AS_DOS_NORMAL 0x00 /* normal file (all bits clear) */ + #define AS_DOS_READONLY 0x01 /* file is read-only */ + #define AS_DOS_HIDDEN 0x02 /* hidden file (not shown by DIR) */ + #define AS_DOS_SYSTEM 0x04 /* system file (not shown by DIR) */ + #define AS_DOS_VOLID 0x08 /* volume label (only in root dir) */ + #define AS_DOS_SUBDIR 0x10 /* file is a subdirectory */ + #define AS_DOS_ARCHIVE 0x20 /* new or modified (needs backup) */ + + /* entry ID 13, short file name on AFP server - arbitrary length + * octet string; usualy printable ASCII starting with + * '!' (0x21) + + + +Faltstrom, Crocker & Fair [Page 15] + +RFC 1740 MIME-based Mac files December 1994 + + + */ + + struct ASAfpInfo /* entry ID 12, AFP server file information */ + { + uchar8 filler[3]; /* filler, currently all bits 0 */ + uchar8 attr; /* file attributes */ + }; /* ASAfpInfo */ + + typedef struct ASAfpInfo ASAfpInfo; + + #define AS_AFP_Invisible 0x01 /* file is invisible */ + #define AS_AFP_MultiUser 0x02 /* simultaneous access allowed */ + #define AS_AFP_System 0x04 /* system file */ + #define AS_AFP_BackupNeeded 0x40 /* new or modified (needs backup) */ + + struct ASAfpDirId /* entry ID 15, AFP server directory ID */ + { + uint32 dirid; /* file's directory ID on AFP server */ + }; /* ASAfpDirId */ + + typedef struct ASAfpDirId ASAfpDirId; + + /* + * The format of an AppleSingle/AppleDouble header + */ + struct AppleSingle /* format of disk file */ + { + ASHeader header; /* AppleSingle header part */ + ASEntry entry[1]; /* array of entry descriptors */ + /* uchar8 filedata[]; /* followed by rest of file */ + }; /* AppleSingle */ + + typedef struct AppleSingle AppleSingle; + + /* + * FINAL REMINDER: the Motorola 680x0 is a big-endian architecture! + */ + + /* End of applefile.h */ + + + + + + + + + + + + +Faltstrom, Crocker & Fair [Page 16] + -- cgit v1.2.3