Subject: Re: [netatalk-admins] DID and Trash problems (was 1.4b2+OS8 / Trash Problem (even with asun patch))
From: DueTc (DueTc@email.msn.com)
Date: Fri Jul 17 1998 - 16:50:33 EDT
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. <bsmith@h-e.com>
To: netatalk-admins@umich.edu <netatalk-admins@umich.edu>
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))
>
>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