Subject: Re: "DID conflict" log message, an explanation and thoughts
From: Netatalk (atalk@abarrach.franken.de)
Date: Sat Dec 23 2000 - 07:44:28 EST
On Tue, Dec 19, 2000 at 05:33:56PM -0800, Glenn Trewitt wrote:
> Session 1 Session 2 Comments
> --------- --------- --------------------
> Open "AAA" Open "AAA" Works fine, no surprise.
>
> Close "AAA" Close "AAA"
>
> Rename "AAA" -> "XXX" Works fine.
>
> Close & Reopen Folder still named "AAA"!
> home directory Get the "DID conflict"
> log message for "AAA" and "XXX"
> from Session 2's afpd process.
Is this with the latest version of netatalk from sourceforge? My clients
see updates as soon as the folder is reread/reopenend. Client 2 should've
seen the update by Client 1, so no AAA dir should appear. The DID conflict
does occur here, too.
> The correct solution, of course, is to have a persistent, shared database for
> the DID->directory mapping. Then, the afpd clients would stay in sync.
> However, there are two problems with this:
> 1) You'll take some sort of performance hit by doing a DB lookup each
> time you enumerate the contents of a directory. This could be bad.
Think broader: not only store DID/name info in the Database, but every
information afpd needs to enumerate a directory. This was suggested long time
ago to speed up directory lookups drastically. Then on directory lookup, just
check if the directory changed in between (simple stat). Using shared memory
or mmapped files between the afpd processes with appropriate synchronization,
this could boost directory lookups by factor 3 easily.
But more and more doubts creep up if this is really the 'right' way to do it.
For every solution I find to an update problem (and we'll encounter them) a new
case pops up where this solution produces further problems. I keep thinking
that the easiest and cleanest way would be to add the info stored in the
.Appledouble files into a separate stat-like block in reiserfs and let the
OS take care of these update problems. Great for linux, but what
about *BSD or Solaris? *argl*
Another way: tie this database into the file access functions in libc
(LD_PRELOAD) ... advantage: all file utils (even samba) would automagically
update the DB, too.
> 2) If you use symlinks (no loops, please!) to make structured
> filesystems for
> sharing folders, a global DID->dirname database would fail, because,
>
> from the point of view of each afpd process, those directories
> really do have
> different names. (I do this on quite a large scale.)
Why is this the case? The relevant DID imho should be the DID of the target
directory the link points to. Afaik nothing disallows THE SAME directory to
occur in different locations in the file tree. Just store one access path
in the database (preferably the real one without symlinks).
Roland Schulz
atalk@abarrach.franken.de
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:50 EST