Subject: [netatalk-admins] DIDs - an idea -or- I didn't read the AFP specs completely yet
From: Andras Kadinger (bandit@freeside.elte.hu)
Date: Tue Apr 14 1998 - 21:03:54 EDT
Dear List Readers,
I was thinking about the DID issue, and hunted down Inside Appletalk,
where in the AFP section I found a sentence stating, that a DID should
never be assigned to a different directory during the lifetime of the
volume. This made me think about a somewhat dirty hack, which seems to
work in theory until now - please, disprove me in either direction. :-)
For we can not use a DID number we already used, we should maintain a
'high water mark' for the volume, like .maxDID or .AppleDouble/.maxDID.
When we create a directory (or find one without a DID, like one created in
unix), we assign maxDID to its DID, store it as - let's say -
.AppleDouble/.DID, and then bump .maxDID.
Looking up the directory's DID is as simple as getting the value from
.AppleDouble/.DID - no database lookups or other complex issues, making
this approach ideally suited for use in a Quick Hack (tm) environment. If
someone moves or renames the directory, the DID holds, and fulfills its
purpose. If someone removes the directory then the DID is also lost, but
with around 2^32 possible DIDs for a volume most of us can live for a
while (remember, this is supposed to be only a quick hack :-) ) - not to
mention Inside Appletalk's explicit behaviour requirement. I think,
locking the volume's .maxDID as a complete file (since it doesn't hold any
other information) would not be an issue for most unices netatalk runs
under - I hope I don't step on a toe here.
This seems to be too simple for me to believe it's right.
Where am I wrong?
Wesley, would this fulfill Your requirement for the DIDs to be stored in
the filesystem? Would this work across NFS?
Sincerely,
Andras Kadinger
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:20 EST