Trash
James Livingston
jrl at ids.org.au
Thu Dec 1 15:29:36 GMT 2005
On Thu, 2005-12-01 at 15:01 +0000, Sam Morris wrote:
> Isn't there a freedesktop.org trash specification that explains how to
> handle stuff like this? <http://www.ramendik.ru/docs/trashspec.html> is
> the best page I can find:
>
> > The implementation MAY also support trashing files from the rest of
> > the system (including other partitions, shared network resources, and
> > removable devices) into the “home trash” directory . This is a
> > “failsafe” method: trashing works for all file locations, the user
> > can not fill up any space except the home directory, and as other
> > users generally do not have access to it, no security issues arise.
> >
> > However, this solution leads to costly file copying (between
> > partitions, over the network, from a removable device, etc.) A delay
> > instead of a quick “delete” operation can be unpleasant to users.
> >
> > An implementation may choose not to support trashing in some of these
> > cases (notably on network resources and removable devices). This is
> > what some well known operating systems do.
> >
> > It may also choose to provide trashing in the “top directories” of
> > some or all mounted resources. This trashing is done in two ways,
> > described below as (1) and (2).
>
> Where (1) describes a sticky .Trash directory at the top level of a
> mounted filesystem, where trashing a file creates (and moves the file in
> question to) /media/foo/.Trash/$user; and where (2) describes on-the-fly
> creation of (and moving the file in question to) /media/bar/.Trash-$user.
>
> Since you (likely) have write access to your 60 GB mp3 player at
> /media/usbdisk, a trashed file would be moved to
> /media/usbdisk/.Trash-james.
>
> In fact this is what Nautilus seemed to do on a system running Breezy
> when I deleted some folders on my brother's mp3 player. We spent a while
> wondering where the 4 GB of space had gone before he noticed the
> .Trash-sam folder containing the 'deleted' files. :)
That is essentially what the issues are:
* Using per-mount trash directories doesn't free the space on the device
until you empty the trash, causing people to wonder where there space
has gone.
* Using "home trash" is bad for large files or network mounts, because
there are slow operations. It can also cause the user to fill their
quota or home partition, which isn't nice.
* Deleting immediately will cause data loss for people who expect it to
be put in the trash, and want to recover it later.
Pick one of the options will have disadvantages for certain media, or
certain situations.
Picking more than one, and switching depending on the media or
situation, will lead to users not being sure what will happen. This is
particularly bad for removable media, since the best choice for "small"
and "large" media and files is different, and how you define "small" and
"large" will be arbitrary.
I don't know what the solution is, because there are considerable
trade-offs that will affect a reasonable number of users.
James "Doc" Livingston
--
Died. Woke up in Hell. Punched in PIN, logged on. Just another day."
-- David Gerard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051202/e9c765a3/attachment.pgp
More information about the ubuntu-devel
mailing list