Subject: afpd.mtab

From: Lorenzo Perone <[email-masked]>
Date: Wed, 19 Dec 2001 22:49:14 +0100

some mtab questions.... anyone here knows the answer? 
(would be nice to have a README.didscheme, anyway, which could give an overview of advantages/disadvantages of a certain scheme...)

1) what's the difference between mtab and old?
2)  what happens when netatalk is configured --with-did=mtab
but no afpd.mtab file exists?  BTW, is the default config directory inherited by the mtab-part of the code (so now it should be /usr/local/etc/netatalk/afpd.mtab)?

Thanx,

:-)

Lorenzo

---

From: Thomas Kaiser <[email-masked]>
Date: Thu, 20 Dec 2001 09:26:34 +0100

On Wed, 19 Dec 2001 22:49:14 +0100, Lorenzo Perone wrote:

> (would be nice to have a README.didscheme, anyway, which could give an
> overview of advantages/disadvantages of a certain scheme...)

Look into the doc/ directory of netatalk 1.5 or here:
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/netatalk/netatalk/doc/>

> 1) what's the difference between mtab and old?

Old "or last-did" means that each afpd increments an ID counter on its own,
which means, the first file a mac accesses gets 1, the second 2 and so on
(not strictly correct but simplified for better understanding)

Main disadvantage: IDs are only valid on a per-session base, so mechanisms
that rely on file oder directory IDs will fail (well-known example: aliases
point to notwhere after remounting a share -- IMO not true with MacOS 8.6 to
9.2, where the Finder prefers searching by path if the location of a file
hasn't changed. But many other softwares that rely on IDs will fail also,
eg. Quark Xpress...)

Then there was a solution introduced called inode-kludge. The basis for
assigning an ID will be the inodes of the underlying filesystem. Under some
circumstances the used alorithm produced duplicate IDs, which is really bad
(since problems appeared with deleting the wrong folders -- they changed
while sitting in the Network Trash Folder on the Netatalk server). So mtab
has been developed to prevent this by configuring the shared filesystems to
use the best compromise for compressing the major, minor device numbers and
inodes into a 32 bit value for the ID (see README.mtab for further details)

Main disadvantage: This isn't a correct ID implementation too. The concept
of IDs keeps in mind, that you can move a file/folder around and still find
it by it's unique unchanged ID. When moving files/folders with mtab, the IDs
will change (if moved accross file system boundaries)

Second problem: Even if you have unique IDs, you will run into problems if a
file/folder will be deleted on the server as this inode will be recycled
instantly. This is also bad, as problems with client-side ID caching can
occur (<http://www.umich.edu/~rsug/netatalk/archive/admins/2000/3251.html>)

Have a look at this excellent synapsis too:

<http://www.umich.edu/~rsug/netatalk/archive/admins/2000/3325.html>

In my opinion, the only way to get real AFP-conformance (avoiding alias
problems, application problems and data loss by duplicate or reused
directory IDs) will be a database-driven solution. The netatalk developer
community is on the right way with CNID (many many thanks to Joe Clarke!).
But from my point of view we will really get into trouble when handling
files without notifying the database (that mean's handling files in any way
expect via afpd --> via UNIX commands, Samba, NFS or another afpd that
maintains a different database and so on...)

Unfortunately I haven't had the time already to test this in depth. But my
limited testing showed similar problems as I had with Helios' EtherShare
(avoiding the use of their desktop utilities that can keep the database
up-to-date when handling files)

Best regards,

Thomas

---

From: Lorenzo Perone <[email-masked]>
Date: Thu, 20 Dec 2001 14:16:26 +0100

Thanx a lot for this info...
mails like these should go into some contrib-README...

BTW,
It's a hard issue, thisone.
On one side, netatalk talks 'afp', on the other hand, it has to deal with non-hfs filesystems, which creates conceptional issues above all.

I think Apple should implement much better the 'foreign filesystem' layer of the network fs drivers (clients) in OSX. Such a layer already exists, it is one of the core abstraction-jewels of OSX.
But it should offer to all filesystems more options, to honour the efforts made:
For example, protocol-independant network share options, settable by the server as well as by the experienced user/admin (such as: supports DID or not; supports creation of invisible resource files or not; supports resource forks or not; etc...).
It's Apple who made the mess, and Apple should provide well made, elegant, easy means to get out of the mess cleanly... ;-)

Regards,
Lorenzo