Re: [Netatalk-admins] Network Trash Folder (is it possible?)

[Thomas K. <Tho...@ph...>]

Damon Timm wrote:

> I have installed libtrash and see that it works in bash with the "rm" com=
mand
> (I had to enable it using LD_PRELOAD) ... things go into the Trash ...
> however, it is not working with netatalk just yet.

Apple's network trash feature has always been a client side feature and not
one of the server (the clients forced the server to create the "Network
Trash" folder, create the appropriate subfolders, get/set the locks, etc.)

Have you thought about the ability to empty the trash from the client-side
with the Finder? If you do you will eventually realize that the Finder's
'network trash behaviour" is solely a client-side issue and has nothing to
do with the filesharing protocol or server implementation and cannot be
fixed 'on the server's side'.

I believe the reason why Apple dropped this general network trash behaviour
with MacOS X is that they couldn't prevent abuse due to the fact that MacOS
X is also a multi-user operating system so a 'per client machine" attempt t=
o
lock/protect specific individual network trash cans couldn't work any longe=
r
in a sane way (compare with [1] to see how the traditional network trash
method worked)

Note: if one uses 'networked home directories' the situation described abov=
e
doesn't apply since the homedir feature itself ensures that there are no tw=
o
or more users eventually sharing the same volume and trash can. They simply
access ~/.Trash which is located on a (netatalk) server by coincidence ;-)

But this is totally unrelated to a general network trash approach for
volumes that are to be accessed by many users simultaneously. Unless Apple
provides a new and multi-user-aware network trash behaviour (maybe as part
of an upcoming AFP version) there is no way to implement it -- hacks like
libtrash included. So visit

    <https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa>

and file a bug report and hope _if_ they plan to address this problem in th=
e
future they do it in a way that is independant from the AFP version in
question (because I believe there won't be any 3rd party AFP implementation
available beyond AFP 3.1 since the requirements to integrate an Open
Directory clone or the like to implement the full AFP 3.2 feature set)

Regards,

Thomas

[1]=A0<http://www.macos.utah.edu/documentation/servers/asip_black_magic/netwo=
r
k_trash.html>