Subject: Re: [netatalk-admins] enumaration optimization/trash can problem...
From: bsmith@h-e.com
Date: Mon Mar 30 1998 - 22:43:05 EST
Original message sent on Sun, Mar 29 12:46 AM by mail-atalk@fizbin.com (Harry
Zink) :
> What worries me on a different level is the 'trash can' problem, which
> could be a permissions issue, but could probably be very easily resolved
> by s a slight change in the code.
The fix probably will turn out to be very simple, however I don't think it is a
permissions problem. Any client can create the first trash folder, "Trash Can
#2", if there are no existing "Trash Can #xx" folders at all. The problem
occurs when a client needs to create a second folder. This rules out an obvious
permissions problem; it is possible for the client to create the folder, it just
doesn't. A few attempts to debug this with "afpd -d" confirm that, I can see no
errors or other indications of why the client doesn't create the folder, as far
as I can tell it doesn't even try!
> Instead of creating 'trash folder #xx', why not just create folders
> labeled 'trash can folder_username_xx'?
It isn't up to afpd what the trash folders are called, the Mac client names
them. As far as afpd is concerned the trash is just a bunch of ordinary
folders, there is no special handling of trash issues in the server code,
everything is handled by the client. This is why the trash should just work,
and why the problem is so mysterious. Anyway, the reason that the work-around
works is that the client goes looking in "Network Trash Folder" for a
pre-existing "Trash Can #xx" that it can write to; I think it does this in case
there is one left over from a previous session that wasn't closed gracefully
(i.e. the client Mac crashed). Whatever the reason, because it does this,
making sure that the "Trash Can #xx" folders always already exist works around
the problem.
> That way, each logged in user definitely creates and gets a unique trash
> can assigned to them. The only problem I see is when you have a user
> logged in multiple times (a possible situation), and you end up with
> multiple trashcans for the same user... this could lead to deletion
> nightmares.
Each connected client should have a separate and exclusive trash, regardless of
user identity. If several clients share a trash folder, any one of them can
empty the trash and thus delete files put there by somebody else, which defeats
the whole concept of the trash. Note, however, that this doesn't work with
netatalk 1.4b2 because the protocol involves byte-range locks on the file "Trash
Can Usage Map", and 1.4b2 it doesn't implement byte-range locks (and to answer
the obvious question, no, this doesn't have anything to do with the problem of
creating the folders, the locks don't happen until after a folder is created).
This is a potential problem with the work-around method if you are running 1.4b2
and have multiple clients connected as the same user. 1.4b2+asun might fix
this, Adrian says byte-range locks work in his patches, but I haven't tested it.
Hope this helps!
Bob
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:32:04 EST