Trash spec: need decisions on some points

[Mikhail Ramendik]

Hello,

David Faure wrote:


> > 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:)

I'm all for "original location". "Initial" sounds like "where the file
was created", and here we have "where the file was before it got
deleted".

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

OK.

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

If we honor absolute paths on removable devices, one could make a
"trojan device" which would show a file allegedly "deleted from the hard
drive" in the Trash view!

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

OK. Let's leave this alone for the implementation. I will recommend
making "full trash emptying" an operation done from root, and granting
user access to it, when necessary, by separate means. 

I can think of a number of implementations that don't even involve suid;
notably a trash cleaning daemon, and a FIFO or flag file for it, and
access control to this FIFO/file. 

A side note... This seems to be a result of absence of ACLs. With ACLs
one could always give privileges to all trash folders to those with the
"clean the trash" right. But Unix historically does not have ACLs, and
we can't expect everybody to switch to XFS.

(We're way beyond what Windoze does in its Trash anyway, even with all
those NTFS ACLs... Windoze Trash is designed as merely a personal
thing).

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

This can be one of the recommended ways for shared resources and
removable devices... Will include it in the spec.

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

Trash dirs in non-$topdir would be somewhat hard to find from another
machine. 

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

OK.

Yours, Mikhail Ramendik
(turning to writing... in OpenOffice HTML editor - I don't speak TeX,
sorry; we can do conversions later)