Subject: Re: [netatalk-admins] DID and Trash problems (was 1.4b2+OS8 / Trash Problem (even with asun patch))

From: [email-masked] (Bob Smith, Hammett & Edison, Inc.)
Date: Thu, 16 Jul 1998 19:21:00 -0700

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

---

From: "DueTc" <[email-masked]>
Date: Fri, 17 Jul 1998 13:50:33 -0700

HMMMMM.

Could this be related to a problem that just showed up the last 2 days on
one of my client networks?   Everyone there works pretty much off the same
shared volume, and once yesterday, and once the day before, a big folder of
important files "placed itself" in the network trash folder of one of the
machines.  A user drug it out each time.  Then later, as the story goes,
another user discovered that all the files and folders from within that
folder were now out of it, and in the same level directory.  Meanwhile, when
that user tried to delete the self-trashing folder (with the intent of
re-creating it), he got a message that the folder could not be found (even
as he was looking right at it).  I had him reset the server (it's a small
firm, luckily), and all seemed to normalize after that, but I had no
explanation.  This is sounding like it's a possibility.

erict

-----Original Message-----
From: Bob Smith, Hammett & Edison, Inc. <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Thursday, July 16, 1998 9:50 PM
Subject: Re: [netatalk-admins] DID and Trash problems (was 1.4b2+OS8 / Trash
Problem (even with asun patch))

---

From: [email-masked] (Bob Smith, Hammett & Edison, Inc.)
Date: Fri, 17 Jul 1998 15:33:15 -0700

>explanation.  This is sounding like it's a possibility.

Well, the part about not finding a folder that was in plain sight definitely
sounds like a DID problem.  But the other symptoms I'm not so sure about, I
don't quite see how a DID confusion could cause a folder, or it's contents, to
spontaneously move around or into the Trash.  Ultimately nothing actually
moves around on a volume unless afpd makes Unix syscalls to do the moves, at
which point everything has been reduced to pathnames and DIDs are irrelevant.
 But I suppose it's possible, things can get pretty weird sometimes!

Bob