Trash spec: need decisions on some points

[David Faure]

On Sunday 29 August 2004 00:36, Mikhail Ramendik wrote:
> 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. 
(BTW is "initial location" better than "original location"? I never know which one to use:)

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

Hmm, didn't realize that. You're right.

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

> an implementation can choose to only honor absolute values in $HOME/.Trash (?)
Hmm, not sure we want that, given that the purpose here is interoperability,
especially on removable devices.

> 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!
Doing anything with other people's files will have major privacy issues.

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

Well, this kind of problem wouldn't happen with a ~/.Trash-only solution :-)
Only the home of the user could fill up, and that can be controlled with quotas.

> 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.
That's where I see a privacy issue - the name in itself can be quite explicit
(mp3s, porn, private documents...). See my other mail for how this could
come from private files (chmod g-rwx on the directory), even if the group 
shares a base directory.

> besides, those with no access to the shared resource don't get to see
> the trash.
But every separate group that has access to the shared resource (but would
normally only have access to a per-group subdir of it), would see everyone
else's trashed files - so the visibility escalates here as well. At least the
groups/<groupname> idea avoids that part.

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

> Or perhaps, in some cases, we might need info files for lower branches,
> and thus, a tree under .Trash/info ?
I don't see when this would be needed. Every move-to-trash operation
creates a single info file. Either you deleted the lower branch first (and then
it has its own info file, and its own tree under .Trash/files/) or you deleted
it together with the rest, and it doesn't have any specific info.

Thanks.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).