Subject: [netatalk-admins] Update: locked file and Trash problems
From: bsmith@h-e.com
Date: Sat Mar 14 1998 - 20:18:55 EST
I just compiled and tested the base netatalk 1.4b2 without any asun patches, and
it has the same behaviors, allowing writes to locked files and not letting more
than one person use the Trash on a shared volume. So this isn't just a problem
with asun's version. I'm less concerned than I was about the locked file issue,
since the same desired result can be achieved by just changing permissions on
the folder containing the file so it is read-only. However the Trash problem is
still a biggie.
I've done some debugging, but I can't find anything in the code that is
Trash-specific other than a fix that makes the DID for "Network Trash Folder"
always the same. I can't see how that would cause this problem, if anything it
should help. The glitch seems to be with creation of the "Trash Can #N"
sub-folders in the "Network Trash Folder", there should be one such folder for
every client currently using the Trash. However only the first one ever gets
created (it's #2, not #1, although I seem to recall a "real" AppleShare server
does the same thing). The next client using the Trash should cause the creation
of "Trash Can #3", but this never happens, the client just gets the "Can't be
left in Trash" error.
However, if I go in from the Linux side and manually create "Trash Can #3", a
second person can then use the Trash! I tried this with up to 4 "Trash Can #N"
folders and it seemed to work. I thought of "priming" the whole system by
creating "Trash Can #N" for all possible users, but the problem is each client
removes it's "Trash Can #N" when the volume is un-mounted. Making "Network
Trash Folder" itself write-locked would prevent this, but sounds risky. From
another angle, a code fix might be to modify afpd to create a "Trash Can #N" for
it's client when a volume is mounted. But with either of those solutions, the
obstacle is that I don't see how each AppleShare client would know which folder
belongs to whom! Is that what the "Trash Can Usage Map" file is for? That file
is always zero length, no data or resource just the AD header stuff, so if there
is supposed to be anything put in there it isn't getting done. Is that the
actual problem here? Hmm, maybe I should fire up the old AS 4.2.1 machine and
take a look at what it puts in "Trash Can Usage Map"...
Anyway, possible hacks aside, I'm really having trouble believing this is a
problem with afpd; having the Trash not work is a HUGE bug yet it isn't
mentioned in any FAQ or buglist file. I hope this is just a local configuration
problem, but if so I'm at a complete loss as to what I'm doing wrong.
HELP?!
Bob Smith
Hammett & Edison, Inc.
bsmith@h-e.com
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:31:39 EST