Subject: [netatalk-admins] Work-around for the shared Trash problem

From: [email-masked]
Date: Thu, 26 Mar 98 19:21:23 PST

As I promised a while back (and prompted by Harry's post about his "shoot-out"
of Linux/netatalk vs. NT vs. etc.), here is the work-around I have been using to
allow the Trash to be shared on an afpd volume.  This isn't going to work for
everyone, it's only manageable if you have a relatively small number of
potential Trash users on the volume.  Also, the "real" problem that prevents the
client from creating Trash folders on its own is still lurking somewhere, the
work-around really shouldn't be necessary, but for now it does the trick.

First, apply the patch to afpd that is attached to this message and re-compile. 
Two versions of the patch file are attached, one for base 1.4b2 and one for
1.4b2+asun2.0a18.2, be sure to get the correct one.  This fixes what might be a
bug in afpd, or it might just be an otherwise non-existent problem that is being
created by doing funky things with the Trash folders (see a more detailed
explanation below, if you're curious).

Next, from the Unix side of things, create a set of "Trash Can #N" directories
starting at #2 (i.e. "Trash Can #2", "Trash Can #3", etc.) inside the "Network
Trash Folder" in the afpd volume root.  Create one folder for each user who
needs to use the Trash on the volume.  This is why this only works for a few
users; I have 12 users, and it works fine for that number, but if you had
hundreds of these things to create I'm not sure it would fly.  Each of these
directories must be owned by one of the specific users needing the Trash, and
must have mode 700.  If any one of the "Trash Can #N" folders is group or world
read or read/write, the whole thing won't work, so be sure to get the owners and
modes right.  Finally, "chmod a-w" the "Network Trash Folder" itself, so the
"Trash Can #N" directories can't be removed by afpd.

Now shared Trash should work!  Everyone who mounts the volume with a user
identity matching one of the "Trash Can #N" directories will be able to use the
Trash, and all those users can put things in the Trash at the same time.  For
any user who doesn't have a "Trash Can #N" owned by them, they will simply get
the "can't be left in Trash, delete immediately?" bit.

If you're interested, here is further explanation of the afpd patch.  The patch
fixes the afp_moveandrename function to keep it from failing on a move or rename
if an ".AppleDouble" directory doesn't already exist in the destination
directory (the patch causes it to create the directory when it isn't there). 
The problem occurs because the Mac client attempts to completely delete it's
"Trash Can #N" when the volume is un-mounted.  Although the directory itself
stays put because "Network Trash Folder" is write-protected, everything inside
the directory goes away, including the ".AppleDouble" directory.   Later when
the volume is re-mounted, files are put in the Trash by afp_moveandrename calls,
and since the ".AppleDouble" directory isn't there, the moves fail; actually,
the files get "broken" - the data files move, but the header/resource files stay
where they were.  The chances of this happening outside these pre-created Trash
folders is probably next to nil unless you deliberately tried to cause it, so
whether this would really be classified as a bug or not is open to debate.  But
if you're going to try this work-around for the Trash you have to apply the
patch.

I've been running with this setup for about two weeks, with a dozen people
making moderate to heavy use of several shared volumes, and it continues to
function just fine.  But I only have a single system to test this on and I have
no idea what problems might crop up in other environments, so I still have to
say "use at your own risk"!

Bob Smith
Hammett & Edison, Inc.
[email-masked]

P.S. - sorry this isn't MIME; got to get a new mail system someday.