Subject: "DID conflict" log message, an explanation and thoughts
From: Glenn Trewitt (trewitt@research.bell-labs.com)
Date: Tue Dec 19 2000 - 20:33:56 EST
Mike Johnson wrote:
.... many details about testing for DID conflicts ....
Thanks, Mike, for the crucial starting point!
This is with version 1.4b2+asun2.1.4-39-test running on FreeBSD 4.2. I'm
quite sure that network configuration doesn't matter one little bit.
Here is a much simplified test case that produces the same error. See the
end for my explanation of what's going on and a brief discussion of what
might be done about it.
Cause a folder named "AAA" to exist on a server (e.g., underneath your home
directory). Log into the server via AppleShare as yourself. Log in again
(also as yourself) from another computer. Do the following:
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.
Open "AAA" Get Finder error "The folder
"AAA" could not be opened,
because it cannot be found."
Here's some extra credit work:
Create a new Works fine.
folder named
"AAA"
Close & Reopen OS 8.6: Now, there are two
home directory "AAA" folders! Both of them
have the contents of the
newly-created "AAA" folder.
OS 9.0: You see two "AAA"s
for a moment, then the second
one disappears!
I could go on (and I did, but things just got more and more weird).
Explanation: Each afpd process keeps a map of DID -> directory, all
independent of each other. As long as directory names don't change, all of
these maps are identical, because (as of this version of netatalk) DIDs are
computed from DEVICE+INODE.
When one afpd changes the name of a directory, it is able to update its DID
-> directory map. The other afpd process is stuck with the DID pointing at
the old directory name. Two separate things then happen:
1) When the Mac with the stale afpd process tries to enumerate the contents
of the home directory (when you close and re-open it), it sees a new
directory with the same DID. When it tries to insert that into its DID ->
directory map, it notices the duplication and logs the error. (This is from
looking at the code.) At this point, the Mac hasn't seen a problem.
2) When you double-click on "AAA" from the stale Mac, the Finder asks afpd
for the folder by its DID and gets the old, now nonexistent, name, returning
an error.
It looks like the code is doing the minimum possible work to deal with this
situation (just enough to keep from getting totally lost). I'm pretty sure
the code could be improved to detect this situation and handle it silently by
updating the stale afpd's state when it comes across the problem. However,
this will still cause problems in the Finder (not seeing the new name until
the folder window gets refreshed). Also (IMPORTANT WARNING) that code may
very well be there from long ago to detect and correct other, much more
pathological, situations. In that case, changing it could have undesirable
side-effects. (A comparison of the prior source should be able to answer
this question.)
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.
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.)
Thoughts to ponder...
Glenn Trewitt
Lucent Technologies Bell Labs Research
Palo Alto, California
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:32:48 EST