Subject: Re: [netatalk-admins] 1.4b2+OS8 / Trash Problem (even with asun patch)
From: Bob Smith, Hammett & Edison, Inc. (bsmith@h-e.com)
Date: Thu Jul 16 1998 - 17:20:30 EDT
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
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:56 EST