hfs.txt

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

  byteorder giving seconds from 00:00 GMT Jan. 1, 2000.

  44..22..  AApppplleeDDoouubbllee HHeeaaddeerr FFiilleess

  Both the fork=double and fork=netatalk schemes for representing forked
  files use AppleDouble header files to contain the resource fork and
  the Finder's metadata together in a single file.

  The AppleDouble format specifies a fixed-format header which describes
  which fields are contained in the remainder of the file, where they
  are located in the file and how long they are.  A full description of
  the version 1 format used when fork=netatalk is available from ??????.
  The version 2 format used when fork=double is documented in ??????.
  The discussion that follows assumes you have read and understood these
  documents, which may be difficult until I've replaced the ``??????''s
  above with something more informative :-).

  Due to the variable structure of an AppleDouble header file you must
  not use buffered I/O when reading or writing them; you should only use
  the read() and write() system calls.  It is also important that you
  make some effort to coordinate processes that are reading and writing
  the same header file, since a reader will receive the wrong data if
  the location of a given entry has changed since it read the descriptor
  for the entry.  If a process tries to read the descriptor table while
  it is changing then it is possible to read totally meaningless data.

  When a header file is opened it is initially presented with a default
  header layout.  You may write to the header to change the layout, but
  when all file descriptors for the file or directory have been closed
  the change in format is lost and subsequent opens will yield the
  default layout.  Changes to supported entries are made directly to the
  filesystem and are thus preserved when the file is closed and
  reopened.

  The HFS filesystem currently uses a fixed-size table to hold the
  descriptors.  Therefore you are limited to HFS_HDR_MAX (currently 10)
  descriptors.  In the unlikely event that you try to write a header
  with more descriptors, a warning will be issued by the kernel, and
  extra descriptors will be ignored.  This should be considered a bug
  and will hopefully change sooner rather than later.

  The results of specifying overlapping entries is undefined and should
  not be relied upon to remain unchanged from one version of the HFS
  filesystem to the next.  There is no valid reason to define
  overlapping entries, so just don't do it!

  Changes to the magic number and version fields are preserved until all
  file descriptors are closed, however the only significance given to
  them internally is that the 16 bytes following the version changes
  meaning according to the version.  For version 1 header files these 16
  bytes contain the string ``Macintosh'' followed by 7 spaces.  For any
  other value of the version field these 16 bytes are all zeros.  In
  either case writes to these 16 bytes are silently ignored.

  Since the magic number and version are given no other significance
  internally, you are free to do many things that violate the official
  formats.  For instance you can create an entry for the data fork in a
  header file with an AppleDouble magic number or create ``File Info''
  (id=7) entries in version 2 header files and ``File Dates Info''
  (id=8) entries in version 1 header files.  However, future versions of
  the filesystem may enforce the format more strictly.

  Entry id 1 (``Data Fork'') is read-only.  You should use the data file
  to modify the data fork.  The data fork is, of course, not supported
  for directories.

  Entry ids 2, 7, 8, 9 and 10 (``Resource Fork'', ``File Info'', ``File
  Dates Info'', ``Finder Info'' and ``Macintosh File Info'') are fully
  supported, meaning that their contents may be read and written and
  that data written is preserved when the file is closed and reopened.
  The resource fork is, of course, not supported for directories.

  Entry id 7 specifies some of the same data given by ids 8 and 10.  If
  you create a header file with an entry for id 7 and for ids 8 or 10,
  then the behavior with respect to their interaction is undefined.  A
  header that contains an entry for id 7 and for ids 8 or 10 is not
  valid as either a version 1 or a version 2 header file, so there is no
  reason to do this and future versions may prevent it.

  Entry id 3 (``Real Name'') is read-only, since it will change
  automatically when a file is renamed.  Writes to the corresponding
  entry are silently ignored.

  All other entry ids are ignored.  You may create descriptors for them;
  in fact the default header layout when fork=netatalk includes a
  descriptor for id 4 (``Comment'').  However writes to the entries
  corresponding to the ignored ids fail silently and reads from the
  entries always return zeros.  However, you shouldn't write random
  bytes to unsupported entries, since they may be supported in the
  future.

  All of the supported entry types except the data and resource forks
  have a fixed length.  If you give them a smaller length in the
  descriptor then you are unable to access part of the corresponding
  entry.  If you give them a larger length in the descriptor, then the
  corresponding entry is padded with zeros and writes to the extra space
  are silently ignored.

  Writes to the length field of descriptors for the data and resource
  forks will cause the corresponding fork to grow (with zero padding) or
  shrink to the indicated length.

  If you have an entry for the data fork then the descriptor's length
  field does not change automatically to reflect any modification of the
  data fork directly (the data does change however).  If the data fork
  is longer than the descriptor indicates, then a portion of it is
  inaccessible.  If the data fork is shorter than the descriptor
  indicates then reads will be padded with zeros.

  Writes beyond the end of the resource fork that extend into empty
  space between entries or beyond the end of the file will extend the
  fork, automatically changing the length field of the corresponding
  descriptor.  Writes to any other space between entries are silently
  ignored and read of such spaces always return zeros.

  Calling truncate() on a header file can change the length of the
  resource fork and such a change will automatically be reflected in the
  length field of the corresponding descriptor.  If truncate() shortens
  the file so that the entry for the resource fork would extend beyond
  the new end of the file then the fork is shortened to fit in the space
  that remains, or to zero bytes if the entry is now entirely beyond the
  end of the file.  If the last entry in a header file is the resource
  fork then a call to truncate() that extends the header file will
  extend the fork with zeros.  Note that this happens even if there was
  previously space between the end of the fork and the end of the file.

  55..  RReeppoorrttiinngg BBuuggss

  If you'd like any problems you encounter fixed, you'll need to provide
  a detailed bug report.  However, you should check the FAQ (available
  from the HFS for Linux Page <http://www-sccm.Stanford.EDU/~hargrove/HFS/>)
  first to be certain that your problem is not a known limitation of the
  filesystem.  If your bug doesn't appear in the FAQ then you should e-mail
  me at [e-mail].

  55..11..  WWhhaatt GGooeess iinn aa BBuugg RReeppoorrtt

  When writing your bug report, include any facts you think might be
  relevant; I'd much rather have a bunch of extra facts than need to
  e-mail you to get the information.  At a minimum the following
  information should be included:

  +o  The version of the HFS filesystem you are using (see
     linux/fs/hfs/version.h).

  +o  The kernel version you are using.

  +o  Any unofficial kernel patches or loadable modules you are using.

  +o  If you are loading the HFS filesystem as a module, then version of
     the module utilities used to load hfs.o.

  +o  The type of media you are working with (floppy, CDROM, ZIP Drive,
     etc.).

  +o  The steps required to reproduce the bug, including mount options
     used.  (If you can't reproduce the bug tell me everything you did
     the one time it did occur, but be warned that non-reproducible bugs
     can only rarely be fixed.)

  55..22..  HHooww ttoo RReeppoorrtt aa KKeerrnneell OOooppss oorr GGPPFF

  If you encounter a bug that causes a kernel Oops or a General
  Protection Fault then you'll need to collect some additional
  information for the bug report.  If you are loading the HFS filesystem
  as a module, then is important that you do this before rebooting,
  since the module is unlikely to be loaded at the same address after
  the reboot.

  You should include all the information that the kernel prints to the
  console or to the system logs.  However, the EIP and Stack Trace are
  addresses in _y_o_u_r kernel and mean nothing to me without more
  information.  Using your System.map file (or either ksymoops or klogd)
  determine which functions the EIP and Stack Trace are in.  If you do
  this by hand using your System.map file then the correct symbol is the
  one of type t or T with the largest address less than or equal to the
  one you are resolving.

  If you are loading the HFS filesystem as a module and the Oops or GPF
  was in the HFS code then the EIP and the top levels of the Stack Trace
  will be in a loadable module, rather than in the kernel proper.  So,
  their symbols will not be in the file System.map.  Therefore, you will
  need to use /proc/ksyms, or a loadmap produced by passing the -m
  option to insmod, to locate those symbols.

  66..  LLeeggaall NNoottiicceess

  66..11..  TThhiiss DDooccuummeenntt

  This document is Copyright (c) 1996, 1997 by Paul H. Hargrove.

  Permission is granted to make and distribute verbatim copies of this
  document provided the copyright notice and this permission notice are
  preserved on all copies.

  Permission is granted to copy and distribute modified versions of this
  document under the conditions for verbatim copies above, provided a
  notice clearly stating that the document is a modified version is also
  included in the modified document.

  Permission is granted to copy and distribute translations of this
  document into another language, under the conditions specified above
  for modified versions.

  Permission is granted to convert this document into another media
  under the conditions specified above for modified versions provided
  the requirement to acknowledge the source document is fulfilled by
  inclusion of an obvious reference to the source document in the new
  media. Where there is any doubt as to what defines ``obvious'' the
  copyright owner reserves the right to decide.

  66..22..  TThhee SSooffttwwaarree

  The HFS filesystem for Linux is Copyright (c) 1994-1997 by Paul H.
  Hargrove.

  This software is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License as published by
  the Free Software Foundation; either version 2, or (at your option)
  any later version.

  This software is distributed in the hope that it will be useful, but
  WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this software in the file ``COPYING''; if not, write to the
  Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
  USA.

  66..22..11..  TThhee CCoolluummbbiiaa AApppplleeTTaallkk PPaacckkaaggee ffoorr UUNNIIXX

  The source code distribution of the Columbia AppleTalk Package for
  UNIX, version 6.0, (CAP) was used as a _s_p_e_c_i_f_i_c_a_t_i_o_n of the location
  and format of files used by CAP's Aufs.  No code from CAP appears in
  the HFS filesystem. The HFS filesystem is not a work ``derived'' from
  CAP in the sense of intellectual property law.

  66..22..22..  NNeettaattaallkk

  The source code distributions of Netatalk, versions 1.3.3b2 and 1.4b2,
  were used as a _s_p_e_c_i_f_i_c_a_t_i_o_n of the location and format of files used
  by Netatalk's afpd.  No code from Netatalk appears in the HFS
  filesystem.  The HFS filesystem is not a work ``derived'' from
  Netatalk in the sense of intellectual property law.

  66..33..  TTrraaddeemmaarrkkss

  +o  ``Finder'' is a trademarks of Apple Computer, Inc.

  +o  ``Apple'', ``AppleShare'', ``AppleTalk'' and ``Macintosh'' are
     registered trademarks of Apple Computer, Inc.

  +o  ``Microsoft'' and ``MS-DOS'' are registered trademarks of Microsoft
     Corporation.

  +o  All other trademarks are the property of their respective owners.