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

From: [email-masked] (Bob Smith, Hammett & Edison, Inc.)
Date: Thu, 16 Jul 1998 14:20:30 -0700

On Wed, Jul 15, 1998, 20:26:57 Tan Chee Weei wrote:

>Using vanilla 1.4b2 with Mac OS8 patch on Linux 2.0.34 (Slackware)
>
>In another issue probably related to the Trash problem discussed earlier:
>
>I am getting the following in /var/adm/debug
>
>afpd[???]:setdirowner:chown -1/0 .AppleDouble/.Parent: Operation not
permitted

Hmm, I never saw that happen on my system (Linux 2.0.32, Red Hat) even when I
was having Trash problems.  Sure sounds like it's related to the Trash issue,
but I'm not sure how.

>Looking at how the Network Trash Can is utilised on a Mac serving with
>Personal File Sharing, each subsequent user of a shared volume gets a new
>Trash Can #n created when they dispose of items (all currently sharing the
>same volume) with n >= 2.  This behaviour seems to be caused by requests from
>the client side and not the server.  Hence, what is it in Netatalk that is
>preventing the correct behaviour for the creation of these Trash Can #n ?  Is
>there some request from the client, while trying to carry out these actions,
>that is denied by the server which prevents it from proceeding correctly?

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.

Someone with more knowledge about AppleShare that I have needs to look closely
into this problem to figure it out!

Bob

---

From: Michael M Han <[email-masked]>
Date: Thu, 16 Jul 1998 15:43:38 -0700

Previously...
>permissions from the Linux side to make sure such folders always exist and

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 ([email-masked])
I will not make flatulent noises in class
 - The collected wisdom of Bart Simpson

---

From: Tan Chee Weei <[email-masked]>
Date: Fri, 17 Jul 1998 12:39:00 +0900

> 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

---

From: Tony Stuckey <[email-masked]>
Date: Fri, 17 Jul 1998 13:19:29 -0500 (CDT)

> make any difference?  Does drwx---rwx = drwxrwxrwx ?

	No, and it shouldn't.
	Excluding a group of users is a perfectly legitimate operation, and
useful in several contexts.  (All classes except freshmen have access to
this directory, etc.)

-- 
Anthony J. Stuckey                              [email-masked]
"When I was young, the sky was full of stars.
 I watched them burn out one by one."  -Warren Zevon