Subject: Re: [netatalk-admins] 1.4b2+OS8 / Trash Problem (even with asun patch)
From: Michael M Han (han@windy.ckm.ucsf.edu)
Date: Thu Jul 16 1998 - 18:43:38 EDT
Previously...
>All that is exactly what I learned in my tests. I even went as far as putting
>afpd in debug mode and looking at the AppleShare transaction trace. There is
>no place that I could find where a request or command from the Mac is being
>denied by the server. At a certain point the Mac does an enumerate of the
>"Network Trash Folder". If that folder is empty, the Mac creates a "Trash Can
>#2" and everything is fine, so Trash works for the first connected user. The
>problem occurs if there is already a "Trash Can #2" in there, then Mac should
>try to create a "Trash Can #3" or whatever; but as far as I can tell it never
>even tries, it just immediately shows the user the "can't be left in Trash"
>error. There is no attempt to create a "Trash Can #3" at all, so the problem
>isn't that afpd refuses to create that folder. My guess is that there is
>something very subtle wrong in the response from afpd to the initial enumerate
>of "Network Trash Folder" which causes the Mac to conclude that there is no
>point in even trying to create new sub-folders. The only thing that avoids
>this is if there are already a bunch of "Trash Can #N" folders pre-existing,
>then if one (and only one) of them is writeable by the Mac doing the lookup,
>it will "adopt" it and use it. My workaround is based on messing with
>permissions from the Linux side to make sure such folders always exist and
>can't be removed.
Looking over afp_openvol() in etc/afpd/volume.c, I found this comment:
/*
* If you mount a volume twice, the second time the trash appears * on
* the desk-top. That's because the Mac remembers the DID for the
* trash (even for volumes in different zones, on different servers).
* Just so this works better, we prime the DID cache with the trash,
* fixing the trash at DID 3.
*/
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...
Just a guess here. A good test might be to create a fresh volume under
netatalk. Connect. Trash something. If my theory's correct, it works
correctly here. Then disconnect and reconnect. Open some folders. Then
try trashing something. Get an error? Looks like a problem with DIDs.
I'd try testing it myself but I'm totally swamped here.
_________
mike (han@library.ucsf.edu)
I will not make flatulent noises in class
- The collected wisdom of Bart Simpson
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:56 EST