Trash spec: need decisions on some points

[Mikhail Ramendik]

Hello,

I am preparing the Trash Spec now. 

I started with a careful reading of the thread. And I see some
(relatively minor) issues that are as yet unresolved. I propose
resolving them somehow, so that the spec can be complete.

1. Absolute vs. relative "original location" in the info files. If it's
absolute (/mnt/flash/dir/origfile.ext), then things get broken on
removable media as soon as it's mounted in a different point, i.e. on a
different machine.

I propose allowing both relative and absolute location values. A
relative value must be from $topdir (where the .Trash dir resides) and
must not contain ".."; it is used for "usual" move-to-trash operations.
An absolute value can be used for trashing-by-copy; an implementation
can choose to only honor absolute values in $HOME/.Trash (?)

2. The question of "accessing somebody else's trash" was already raised.
One only sees files deleted by oneself; what about those deleted by
others?

Of course, wanting to *restore* a file that somebody else has deleted is
a rare operation. We can ignore this safely for now. But wanting to
*clear* all the trash because of disk space concerns can be much more
common!

This is important for shared network partitions and removable devices.
Here's a use case.

Let's say we have a shared project directory on a network, and the
project boss has the right to remove files to make room on the drive. An
employee was being responsible and has removed (actually trashed) some
big files; now he is not available... and the boss has to talk to the
system administrator in order to clear the space!

One idea would be to make "all-users trash" an option, and to recommend
its use on shared resources and removable drives. In this case a
".Trash/allusers" directory would be created in $topdir, and treated
just like a normal user trash - but trashed files from all users will
end up there. The ownership and access rights would be preserved from
the original files, so it's not much of a security concern; everyone
would be able to see a list the trashed files, but not the contents.
besides, those with no access to the shared resource don't get to see
the trash.

Note that the option is to be for a *mount point*, not for the entire
machine. So we can have "allusers trashing" on shared resources and
removable devices, and "mormal trashing" everywhere else.  

But this complicates implementation. Even if "allusers" trashing was
enabled at one machine, it can be disabled on another. So, when reading
a trash, a system would need to aggregate the "allusers" trash and the
current user's trash (if both are present) into one. 

I'm not a big proponent of this idea; I just don't see any others. I'll
document the decision which the group here will (hopefully) reach.

3. It was repeatedly said here that, when a directory is deleted, an
info files is only needed for the directory itself, not files and
subdirectories in it. Do we make it a simple and clear rule - that info
files exist only for files and directories in the .Trash/files dir
itself, not for anything in those directories? In other words, that
there are no subdirs in .Trash/info ?

Or perhaps, in some cases, we might need info files for lower branches,
and thus, a tree under .Trash/info ?

That's all for now :) I more or less have the structore of the spec in
my head, and hope to present something readable by Tuesday evening at
the latest (and hopefully tomorrow).

Sincerely yours, Mikhail Ramendik
Technical writer