Re: [netatalk-admins] Network Trash Folder

[Bob Smith, Hammett & Edison, Inc.]

On Wed, Mar 10, 1999, 22:41:00 Michael Han wrote:

>The permissions/gid problem you can finesse. Or at least you can hack
>around it. The other problem's trickier. There's a gruesome hack
>reported here (was it Bob at h-e.com? sorry, forget your surname) that
>fixes the other problem. In it, you pre-create "Trash Can #N"
>subfolders, mode 700, one per user owned by that user... Ick. But it
>does work. Or did about 10 months ago when I first saw this problem
>reported.

Hi, Michael!  It's Bob _Smith_, I can see how easy that is to forget, what
with the funny spelling and all <G>.

Anyway, as far as I know this "hack" still works.  Certainly it does for older
netatalk releases (i.e. 1.4b2), but I've not tried it on the latest asun
version.  Below is a copy of my original posting, for those interested.  Mike
is right, it is "icky", but it does work!  One of these days somebody will
figure out exactly what is going on with the shared Trash.

Actually, if anyone out there is still thinking about this problem, I stumbled
on an interesting clue the other day.  The Mac will give the "Can't be left in
trash, delete immediately" message when the Trash is used on a _private_
volume if the volume has been mounted and the Trash used from a _different_
Mac.  In other words, assume that volume V is usually mounted and used only
from Mac A.  Now, Mac A is off-line and the user instead mounts V from Mac B,
and uses the Trash (the message sometimes appears from Mac B in this
situation, but not always).  When returning to Mac A, the first attempt to use
the Trash on V will _always_ give the "delete immediately" response.  Second
and subsequent attempts to use the Trash work fine.  However this will _not_
happen if V was merely mounted and accessed from B, the Trash has to actually
be _used_ from B.  This suggests something going on with the modification time
on the Trash folder(s), doesn't it?  I'd really love to spend a couple of days
attacking this, if only I didn't have all this annoying "real work" stuff to
do...

***

>From: [EMAIL PROTECTED]      Thu, Mar 26 1998 19:21
>To: [EMAIL PROTECTED]
>cc: bsmith
>[netatalk-admins] Work-around for the shared Trash problem
>
>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).

I have no idea how this patch would behave on the latest asun release, or even
if it is still necessary with asun, so I haven't included the asun version of
the patch this time.  The version that applies to 1.4b2 is attached, it isn't
complicated, it patches just one routine in one file, so you can probably work
out how to apply it to asun if needed.

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

Hope this helps!

Bob Smith
Hammett & Edison, Inc.
[EMAIL PROTECTED]


(This file must be converted with BinHex 4.0)
:%@&QF'3YE@pfC@*eCbjND@CQ!&4&@&45+Q0S!3!!!!C*!!!!!+ee+LSU)'9dBbp
KCR"N,fCTE'8ZBbd*8f&d)%eKFL!a0#!a0$Sc0MS`0L!a16Ni#LdY,5"PG'-[B@C
`C#pQD@aP,Q-*6@pZ)%eKFL!a0L!`-6S`0$Sd-L!a16Ni#LSU+LSU+LSU+LSU+LS
U+JSU+LSJ0$-f,$3d-L!U+LSU#L!JH`SJ)#!J)#"cG(*eBh3JB@4[G@*XC3PKC$X
+)#!J)#!JFh4bG@0d)(0dBA3*#A0d1`SK)#!J)#"MD'&b#3PKC(0bBeXJ68&B8%&
85%a&6L"G1`SJ)#!J)#"TER3*#3PXC@iX)(*M1`SJ)!SJ)#!J)#![+JSY,5dJ0$-
f,$3d-L!Y,5dY#L!JH`SJ)#!J)#"cG(*eBh3JB@4[G@*XC3PKC$X+)#!J)#!JFh4
bG@0d)(0dBA3*#A0d1`SK)#!J)#"MD'&b#3PKC(0bBeXJ68&B8%&85%a&6L"G,#!
UB@4NFh3X)#TcE'&cD$X+)#!J)#!JD@jd#3N*E'9Z,#"bBcX+)#!+)#!J)#!J,bS
++LSU+LSU+LSU+LSU+LSU#LSU+L!d0MJX0$Fh)#SU+LS+)#!J)#!JI3SJ)!SJ)#!
J)#"cG(*MF(NS)'&NFh*M,#"KC&p`BA4S+#"cFQ-X)$!J+5Nl#L%J)#!J)'PQ)#J
JFQ9ZB@eP+#"KC(0bBb`JB@4IF'&dD#JJC(0d,#!`)#NT)$`J-#!T)(X+)#!*FhG
TG'0S)#JJCA*bEQmJ+5"l#L!J#@0KFf8J48j248j8)$S+)5!*)#!J)(*PG(9bELJ
J38C3Adp,)#Nl#L!J#@0KFf8J48&$3d96)$S+)#!*)#!J)(*PG(9bELJJ38C349*
5Ad&$3d968b!T1`SJ)!PNC@CKG@ad)$S+,5dY)$3f1#`e-$%J,5dY,3SJ)#!J)#"
p#L!J#L!J)#!J)(0dFQ0`H5JJB@4cFQ-X)'&NAh"KG'JS)(0bBb`J-#!T+6X+)5!
J)#!JB@4NFh3J25"KC&p`BA4S+#"NFh3X)$!J+6X+)5!J)#!JD@BJ+#"bC@jKE@8
S)'&NFh*M,#"KC'4cG#!T)$`J-#!T)(X+)#!*FhGTG'0S)#JJCA*bEQmJ+5"l#L!
J#@0KFf8J48j248j8)$S+)5!*)#!J)#mU)%eKH5"LC5"NG@8JG'mJC'9cG'PZBA4
TEfiJ383JC'PbC@0dEh*j)'eTFh0TEQFZ)#"6G'&d)(4SC3SK)!NJ)#!J)#!JFfp
eFQ0P)(4[)'CTEQ3JEh9d)'PQ)'Pd)'9iDA0dFb`JD@BJDA3JC'pPFb`JBh*PBA4
P)(4SC5""4!SK)!NJ)#!J)#!JC'9cG'PZBA4TEfiJC'PbC@0dEh*j)'&ZC#"dFRN
JB@GKD@iZ#L%J#5!J)#!J)#!mBR0YDA4S3'JYC5jMEfdq)#!j1$!c-68J+Lm+)5!
*)#!J)'PQ)#JJFh4KG#JJB@4cFQ-X)#CcG#!T+5"l#L%J#5!J)#!J)(*PG(9bELJ
J38C3Adp,)#Nl#L%J#5!J)#"p#L%J#5!J)#"TCL!S)(0XBA0S)$dJFh4bFQ0SFLJ
JB@4NFh3X)#F[*b!T+5"l#L%J#5!J)#!J)#TcE'&cD#!p)#GF-#Fl#L%J#5!J)#!
J)'PQ)#JJB@4IE@YNDA)S)'&NC(0d,#!`0cFh)#NJ26dJ-#!T)(X+)5!*#5TcE'&
cD#!p)#F[*cX+)5!*#@PQ)#JJFQ9ZB@eP+#"KC(0bBb`JB@4NFh3J+5!p25!`)#N
JH`SK)!N*)#"LFQ9KDcX+)5!*#Ad+)5!*)#!J)#!JI3SK)!NJ)#!JI3SK)#!J)#!
J)#!J)#!J)(0hDA4MD#!S)'9bFQj[)#NJH`SK)!NJ)#!JBf&cC5"&6Np&6P3J1JS
K)!NJ)#!J)#"bCA4eFQiS)%&'8%958Pp16dp#5L!T1`SK)!NJ)#!JBf&cC5"&380
$49-J1JSK)!NJ)#!J)#"bCA4eFQiS)%&'8%958Pp"3d0&8e-J+6X+)5!*)#!J)'4
PCQ&eE(3J1JSK)!NJ)#!J)#"bCA4eFQiS)%&'8%958Pp339*"65!T1`SK)!NJ)#!
JI3SJ)!PMBA0P)%9"3d0&8b!k#L!J#5!J)#"bCA4eFQiS)%&'8%958Pp"3d0&8e-
J+6X+)#!*C'9QBA9XG#!k#Pq%!!!: