About this directory

   This directory contains I hack I wrote to explore a way to fix the
netatalk persistent DID problem.  A survey of the contents:

   README.mtab -- notes for implementors and sysadmins, on why there is
an extra configuration file, and how to maintain it.  If adopted, this
should become part of the distribution documentation.  Much more could
be said.

   afpd-mtab.pl -- perl script that acts as a filter, turning /etc/mtab
into an initial afpd.mtab version.  (Only tested on RH Linux.)

   afpd.mtab.* -- testing versions produced on my system.  "make test"
tries to produce afpd.mtab automatically; if this doesn't work on your
configuration, you could try editing one of these to match your
partition structure.

   parse-mtab.c, parse-mtab.h -- source intended to be integrated into
the etc/afpd/ code.

   test-parse-mtab.c -- test driver for parse-mtab.c, reads the file and
produces CNID values for other files and directories given on the
command line.  Change top_srcdir in the makefile and do "make test" in
order to compile & run this.

Notes:

   * I have only ext2fs partitions on a single local disk, so I haven't
been able to do very broad testing, even on Linux.  This is part of why
I'm too chicken to try to paste this into the netatalk source.  ;-}

   * If there is no entry in the table, I just use the reserved 0 device
index.  This seems like asking for trouble, so a better policy would be
to make absent devices unavailable (you probably don't want users poking
around in /var or /usr anyway), but that requires a more global
implementation.

   * The way it's now written, afpd is expected to fail to start up if
/etc/atalk/afpd.mtab is not found.  That may not be optimal, but even if
it is, it requires some extra setup instructions.

   * I'm assuming the high order bit need no longer be reserved for the
file/directory flag, but I have no idea whether that will work.  If not,
it's easy to change.

   * It would be good if, on startup, afpd would warn about partitions
in the table that have more inodes than can be represented in the
available number of bits.

   * If partitions were to use a bit encoding that reversed the bits in
the index (i.e. putting the LSB "first" as written), then the device MSB
would be adjacent to the inode MSB.  That would produce upward-
compatible DIDs if the number of device bits needed to increase.  The
encoding is precomputed anyway, so it's not a speed concern.  Better
still, by carefully choosing small indices for large-inode devices and
avoiding intermediate-sized indices, one could effectively set the
device/inode boundary independently for each device.  This would allow a
sysadmin to come close to using all of the theoretical 32-bit DID-space.
(Implementation is left as an excercise.  ;-)