hfs.txt

嵌入式系统设计与实验教材二源码linux内核移植与编译

  +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