Subject: Re: [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 - 22:06:47 EDT
Wesley,
On Tue, 14 Apr 1998 wesley.craig@umich.edu wrote:
> > From: Andras Kadinger <bandit@freeside.elte.hu>
> > To: netatalk-admins@umich.edu
>
> > Wesley, would this fulfill Your requirement for the DIDs to be stored in
> > the filesystem? Would this work across NFS?
>
> The only thing you're missing is the need for a DID -> pathname
> database. This is required for resolving aliases, in particular.
> Lacking such a database means searching the filesystem for an
> appropriate DID.
Hmm. Then the .maxDID thing could be expanded to .DIDdb, which would only
be modified when handing out a new DID, or when looking up a pathname from
a DID results in a nonexistant pathname (we might want to fall back to
searching the filesystem in this case, if we care about keeping Mac
aliases for directories moved from unix) - so the whole file locking still
might be feasible. Yes, I knew this was _rather_ lacking somewhere.
> Also, there's the case where someone mounts /home, and you've already
> got /home/bandit mounted.
You mean AFP-mounting 'nested' volumes - subtrees?
1) We might want to say 'don't do that', just like other AFP servers do -
I can not realistically imagine a scenario where such 'nested' mounting
might really need working aliases, but that's only me.
2) We might want to search upwards for a .maxDID or .DIDdb thing, and use
that. If the .DIDdb database stores only relative pathnames from the
AFP-volume's root, using the 'parent's' one for the nested volume
(prepeding the path difference) might be doable, though this is ugly at
first sight.
3) We might want to do automatic .DIDdb updating/building when necessary
(e.g. there is a parent/child dir with a more recent .maxDID).
Did I say Quick Hack(tm)?
Sincerely,
Andras Kadinger
bandit@freeside.elte.hu
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:20 EST