+o  You can't create symlinks, device files, sockets or FIFOs.  33..11..  WWrriittiinngg wwiitthh ffoorrkk==ccaapp  Unlike the other schemes for representing forked files, the CAP scheme  presents the resource fork as an independent file; the resource fork  of ./foo is ./.resource/foo.  Therefore, you can treat it as a normal  file.  You can do anything to a resource fork that you can do to a  data fork, except that you cannot enable execute permissions on a  resource fork.  Therefore, resource forks are not suitable for holding  Linux executables or shared libraries.  If you plan to use the resource fork on a Macintosh then you must obey  the format of a valid resource fork.  This format is documented in  Chapter 1 of Apple's _I_n_s_i_d_e _M_a_c_i_n_t_o_s_h_: _M_o_r_e _M_a_c_i_n_t_o_s_h _T_o_o_l_b_o_x.  The  filesystem knows nothing about this format and so does nothing to  enforce it.  The current support for reading and writing is sufficient to allow  copying of entire directories with tar, as long as both the source and  destination are mounted with fork=cap.  tar may complain about being  unable to change the uid, gid or mode of files.  This is normal and is  an unavoidable side effect of the having a single uid, gid and umask  for the entire filesystem.  It is impossible to create a resource fork or a Finder metadata file.  However, they are created automatically when the data fork is created.  Therefore, if you wish to copy a single file including both forks and  the Finder's metadata then you must create the data fork first.  Then  you can copy the resource fork and the Finder's metadata.  For  instance to copy the file foo to dir/bar you should do the following:  1. cp foo dir/bar  2. cp .resource/foo dir/.resource/bar  3. cp .finderinfo/foo dir/.finderinfo/bar  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  If you wish to move foo to dir/bar and foo and dir are on the same  filesystem then you only need to execute ``mv foo dir/bar'' and the  resource fork and the Finder's metadata will move too.  However, if  foo and dir are on different filesystem then this will lose the  resource fork and metadata.  Therefore, it is safest to always move  files as follows:  1. cp foo dir/bar  2. cp .resource/foo dir/.resource/bar  3. cp .finderinfo/foo dir/.finderinfo/bar  4. rm foo  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  Directories have no resource fork but you may wish to create a  directory which has the same location and view on the Finder's screen  as an existing one.  This can be done by copying the Finder metadata  file.  To give the directory bar the same location, layout, creation  date and modify date as foo you simply execute ``cp .finderinfo/foo  .finderinfo/bar''.  When copying an entire directory with ``cp -R'' you may also wish to  copy the metadata for the directory:  1. cp -R foo bar  2. cp .finderinfo/foo .finderinfo/bar  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  33..22..  WWrriittiinngg wwiitthh ffoorrkk==ddoouubbllee  The current support for reading and writing header files is sufficient  to allow copying of entire directories with tar, as long as both the  source and destination are mounted with fork=double.  tar may complain  about being unable to change the uid, gid or mode of files.  This is  normal and is an unavoidable side effect of the having a single uid,  gid and umask for the entire filesystem.  It is impossible to create a header file.  However, they are created  automatically when the data fork is created.  Therefore, if you wish  to copy a single file including both forks and the Finder's metadata  then you must create the data fork first.  Then you can copy the  header file.  instance to copy the file foo to dir/bar you should do  the following:  1. cp foo dir/bar  2. cp %foo dir/%bar  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  If you wish to move foo to dir/bar and foo and dir are on the same  filesystem then you only need to execute ``mv foo dir/bar'' and the  header file will move too.  However, if foo and dir are on different  filesystem then this will lose the header file.  Therefore, it is  safest to always move files as follows:  1. cp foo dir/bar  2. cp %foo dir/%bar  3. rm foo  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  Directories have no resource fork but you may wish to create a  directory which has the same location and view on the Finder's screen  as an existing one.  This can be done by copying the corresponding  header file.  To give the directory bar the same location, layout,  creation date and modify date as foo simply execute ``cp %foo %bar''.  When copying an entire directory with ``cp -R'' you may also wish to  copy the header file for the directory as well:  1. cp -R foo bar  2. cp %foo %bar  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  33..33..  WWrriittiinngg wwiitthh ffoorrkk==nneettaattaallkk  The current support for reading and writing header files is sufficient  to allow copying of entire directories with tar, as long as both the  source and destination are mounted fork=netatalk.  tar may complain  about being unable to change the uid, gid or mode of files.  This is  normal and is an unavoidable side effect of the having a single uid,  gid and umask for the entire filesystem.  It is impossible to create a header file.  However, they are created  automatically when the data fork is created.  Therefore, if you wish  to copy a single file including both forks and the Finder's metadata  then you must create the data fork first.  Then you can copy the  header file.  instance to copy the file foo to dir/bar you should do  the following:  1. cp foo dir/bar  2. cp .AppleDouble/foo dir/.AppleDouble/bar  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  If you wish to move foo to dir/bar and foo and dir are on the same  filesystem then you only need to execute ``mv foo dir/bar'' and the  header file will move too.  However, if foo and dir are on different  filesystem then this will lose the header file.  Therefore, it is  safest to always move files as follows:  1. cp foo dir/bar  2. cp .AppleDouble/foo dir/.AppleDouble/bar  3. rm foo  You may get ``Operation not permitted'' errors from cp when it tries  to change the permissions on files.  These errors can safely be  ignored.  This method will work even if the file dir/bar exists.  Directories have no resource fork but you may wish to create a  directory which has the same location and view on the Finder's screen  as an existing one.  This can be done by copying the corresponding  header file.  To give the directory bar the same location, layout,  creation date and modify date as foo you simply execute ``cp  foo/.AppleDouble/.Parent bar/.AppleDouble/.Parent''.  Because the fork=netatalk scheme holds the header file for a directory  within that directory, directories can safely be copied with ``cp -R  foo bar'' with no loss of information.  However, you may get  ``Operation not permitted'' errors from cp when it tries to change the  permissions on files.  These errors can safely be ignored.  44..  AA GGuuiiddee ttoo SSppeecciiaall FFiillee FFoorrmmaattss  Each of the values of the fork mount option yields different special  files to represent the Macintosh-specific parts of a file within the  structure of the Linux filesystem.  You can write to these special  files to change things such as the Creator and Type of a file.  However, to do so safely you must follow certain rules to avoid  corrupting the data.  Additionally, there are certain fields in the  special files that you can't change (writes to them will fail  silently).  44..11..  CCAAPP ..ffiinnddeerriinnffoo FFiilleess  The Finder's metadata for the file ./foo in held in the file  ./.finderinfo/foo.  The file has a fixed format defined in hfs_fs.h as  follows:       ______________________________________________________________________       struct hfs_cap_info {               __u8    fi_fndr[32];            /* Finder's info */               __u16   fi_attr;                /* AFP attributes */               __u8    fi_magic1;              /* Magic number: */       #define HFS_CAP_MAGIC1          0xFF               __u8    fi_version;             /* Version of this structure: */       #define HFS_CAP_VERSION         0x10               __u8    fi_magic;               /* Another magic number: */       #define HFS_CAP_MAGIC           0xDA               __u8    fi_bitmap;              /* Bitmap of which names are valid: */       #define HFS_CAP_SHORTNAME       0x01       #define HFS_CAP_LONGNAME        0x02               __u8    fi_shortfilename[12+1]; /* "short name" (unused) */               __u8    fi_macfilename[32+1];   /* Original (Macintosh) name */               __u8    fi_comln;               /* Length of comment (always 0) */               __u8    fi_comnt[200];          /* Finder comment (unused) */               /* optional:    used by aufs only if compiled with USE_MAC_DATES */               __u8    fi_datemagic;           /* Magic number for dates extension: */       #define HFS_CAP_DMAGIC          0xDA               __u8    fi_datevalid;           /* Bitmap of which dates are valid: */       #define HFS_CAP_MDATE           0x01       #define HFS_CAP_CDATE           0x02               __u8    fi_ctime[4];            /* Creation date (in AFP format) */               __u8    fi_mtime[4];            /* Modify date (in AFP format) */               __u8    fi_utime[4];            /* Un*x time of last mtime change */       };       ______________________________________________________________________  The type __u8 is an unsigned character, and __u16 is an unsigned  16-bit integer.  Currently only the fields fi_fndr, fi_attr, fi_ctime and fi_mtime can  be changed.  Writes to the other fields are silently ignored.  However, you shouldn't write random bytes to the other fields, since  they may be writable in the future.  The fi_fndr field is the ``Finder info'' and ``Extended Finder info''  for a file or directory.  These structures are described in various  books on Macintosh programming.  The portion of the most interest is  probably the first 8 bytes which, for a file, give the 4-byte Type  followed by the 4-byte Creator.  The fi_attr field is the AFP attributes of the file or directory.  While you can write any value to this field, only the ``write-  inhibit'' bit is significant.  Setting or clearing this bit will clear  or set the write bits in the file's permissions.  When you read from  this field anything you may have written is lost.  If the file has  write permissions enabled then you will read zero from this field.  With write permission disabled you will read back 0x01 0xA0, which  corresponds to setting the ``write-inhibit'', ``rename-inhibit'' and  ``delete-inhibit'' bits.  The fi_ctime and fi_mtime are the Macintosh created and modified time  for the file or directory, and are 32-bit signed integers in network