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 hargrove@sccm.Stanford.EDU.  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.