Subject: Re: [netatalk-admins] enumaration optimization/trash can problem...

From: Harry Zink <[email-masked]>
Date: Sun, 29 Mar 1998 00:46:42 -0800

>In fact I was thinking about caching type/creator/comment/icon/other
>miscellaneous information with the data the catalogueing daemon proposed
>by Adrian would collect.

This should be very possible by caching the relevant information, and 
before verifying against something like a checksum before reading from 
the cache (to make sure the data is current, and/or hasn't changed - if 
it changed, update the cache...)

We've used this in the case of certain directory cacheing mechanisms, so 
I do not think it would be that impossible to implement.

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.

Instead of creating 'trash folder #xx', why not just create folders 
labeled 'trash can folder_username_xx'?

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.

Of course, this could be eliminated by eliminating the # at the end, and 
only extending the traschcan folder name by the 'username' - then every 
subsequent login under the same name would inidicate the current status 
of the trash can for that particular user...

Do-able???

Harry

---

From: [email-masked]
Date: Mon, 30 Mar 98 19:43:05 PST

Original message sent on Sun, Mar 29  12:46 AM by [email-masked] (Harry

> 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!

> 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.

> multiple trashcans for the same user... this could lead to deletion 

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