Subject: Re: [netatalk-admins] 1.4b2+OS8 / Trash Problem (even with asun patch)
From: Tan Chee Weei (ctan@pacific.net.sg)
Date: Thu Jul 16 1998 - 23:39:00 EDT
Michael M Han wrote:
>
> 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.
Tried that. The thing here is that there is no problem when connecting and
reconnecting, as long as you are the same user. Change the user when
you reconnect and you would see the Network Trash Can on the desktop although
it should be invisible. Don't know why it should show up as visible as I assume
the invisible bit should be set. Try to trash something and it tells you
it can't move it to the trash and asks to delete it immediately.
However, when the permissions on the Trash and subdirectories are set to a+rwx
The behaviour improves. When reconnecting as a different user, the Network
Trash Icon does not show up and the second user is able to move stuff to the Trash
when deleting items. So far so good. However, if another user (could be the same
as the original) were to mount the volume at the same time, then when that user
tries to trash something, he will get the delete immediately message even though
initially he was able to. What happens is that Trash Can #2 now belongs to
the 2nd user on the reconnect. When user 1 connects as well and trashes something,
Trash Can #3 should be created and belong to him. However, this is not created
which is the big question. WHY? So, DID's don't seem to be the reason why
the trash icon shows up. Permissions seem to be the reason behind it. (Can't
get access to the Network Trash's directory attributes?) The hack you mentioned
in afp_openvol should prevent the icon from showing up.
Some thoughts: The Network Trash Folder is created with permissions uo+rwx
with no access to group. Since others have rwx permissions, everyone should
have access to it. However, could it be a possibility that because group has no
access, the fact that others have access is ignored and hence access is denied?
It shouldn't be the case but are there certain checks that erroneously behaves
as such (or even deems such as correct behaviour?) Why is the Network Trash Folder
created with only uo+rwx instead of ugo+rwx. Furthermore, this is inherited by
.AppleDouble with the Network Trash Folder and the Trash Can Usage Map
(and .Parent and Trash Can Usage Map within .AppleDouble). The fact that others
have rw perms should imply access to everyone. Does the fact that g has no perms
make any difference? Does drwx---rwx = drwxrwxrwx ?
Any enlightening input/comments etc. from the authors? (Your work is much
appreciated, truly)
Thoughts, ideas, anyone?
CW
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:56 EST