Subject: Re: [netatalk-admins] DID and Trash problems (was 1.4b2+OS8 / Trash Problem (even with asun patch))
From: Bob Smith, Hammett & Edison, Inc. (bsmith@h-e.com)
Date: Thu Jul 16 1998 - 22:21:00 EDT
On Thu, Jul 16, 1998, 15:43:38 Michael M Han wrote:
>so I'm guessing that the problem is indeed persistent DIDs. Basically
>the Trash folder *always* is set DID 3 on netatalk'd volumes to
>guarantee that Macs can always find the right folder for Trash, but
>the subfolders carry no guarantee that this will happen. But I'm
>guessing that the subfolders are also to be found by DID, and once the
>enumerate on "Trash" comes back with different DIDs from a previous
>session, the Mac decides it's confused and won't try to do trash
>properly...
Hi Michael -
This is a really good possibility, like I said recently I suspect most of the
bizarre little quirks in afpd are ultimately due to the non-persistent DID
problem. The workaround which ensures that the "Trash Can #N" folders are
always present may indirectly ensure that those folders always have the same
DIDs. Assuming that enumerating the "Network Trash Folder" is something done
routinely just after a volume is mounted before any other directories are
scanned, the folders within that folder would always get the same DIDs even
though afpd is not doing anything special to guarantee that.
While we're on the subject of afpd problems, one I reported several months ago
turns out to be due to the DID problem, and I have discovered a somewhat hack-
ish workaround. The problem is that occasionally an attempt to create a new
folder in an afpd volume will fail with an error along the lines of "the
command cannot be completed because the item cannot be found". A bit of
investigation has uncovered this somewhat convoluted explanation.
Macs A and B are both connected to the server with the same shared volume
mounted, and both of them have a Finder window open for that volume, both
looking at the root or the same folder in that volume.
Mac A creates a new folder, which is named "untitled folder". The folder
shortly appears in the Finder on Mac B. This means both afpd sessions have
now assigned a temporary DID to that folder, although probably not the same
DID.
Mac A renames the folder and/or moves it somewhere else, like into another
folder or even the Trash. The folder then disappears from the Finder on Mac
B. This means the DID that Mac B's afpd assigned to the folder is now
"broken", afpd still thinks it is valid but the directory it points to is
gone.
Mac B attempts to create a new folder but fails with the error message,
apparently because it can't find the "untitled folder" created by Mac A.
The workaround is to use ResEdit to hack the Finder on each Mac so that rather
than using "untitled folder" as the name for new folders, each Mac uses a
unique name like "new folder xxx" where "xxx" is different for every Mac.
Then a particular Mac will never recognize some other Mac's new folder as
something it needs to worry about, thus avoiding the problem.
What I think is happening here is that Mac B, having seen an "untitled folder"
appear in the directory, tries to look up that folder using it's DID so it can
decide if it should create "untitled folder 1" or if it can re-use "untitled
folder". But since Mac B's afpd session has lost track of the original folder
created by Mac A, the lookup fails in some unexpected way and Mac B returns
the error. In other words the underlying cause here is a DID getting out of
sync with the directory it's supposed to identify. In this case it isn't
becuase the DID is non-persistent from one afpd session to another, but
because the DIDs for a specifc directory are different between two
simultaneous afpd sessions sharing the same volume. Of course a fix to
implement persistent DIDs would also fix this problem, since it would
guarantee that all afpd sessions, either parallel or serial, would always have
the same DID for a particular directory.
So Wes, Adrian, others, any idea how soon a persistent DID fix might appear?
Bob
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:57 EST