Re: Trash system



#if Maciej Stachowiak
> I think it's nice, for the following reasons:
> 
> 1) Move to Trash is always a fast operation and can't fail for disk
>    space reasons. Imagine if you're a user trying to delete files to
>    make space, and you can't move some items to the trash because of
>    low disk space - this would badly suck from a usability
>    perspective.

True.

> 2) Does the right thing for removable media and network volumes - in
>    this case it really makes sense to store the trash on the device or
>    network volume itself, so you can still undelete from other
>    systems, and so you don't see items in the trash when the disk they
>    came from is no longer mounted.

Yes. I take back my suggestion that copying to the home partition
is a good idea :)

> Some people brought up the fact that there might not be a location
> writable to the user in a given filesystem. However, if there is a
> file they can delete, there must be at least one place where they can
> write, namely the same directory that file is in, as Pavel described.

Ok.

Let's imagine I'm deleting a file /mnt/somewhere/mydata

I have write access on the /mnt/somewhere filesystem. There are
no directories on that filesystem, just a single file called mydata.

The only place I can write to on that filesystem is /. So I could
create a directory called .trash and move the file in there with
a different name, e.g. abcde. I could also safely create metadata
for that file, if I made a rule that temporary metadata files
have a '.' prefix. So I write to .trash/.abcde.info and then
rename to .trash/abcde.info when I'm sure I wrote the metadata OK.

This works fine, although I would still prefer separate directories
in .trash like 'files' and 'info' - for efficiency when reading.

The only problem left is that when the user looks in their trash,
we have to be able to find the directory /mnt/somewhere/.trash. 

Without using find(1), we'd have to write a note somewhere to say
that we have a .trash directory in /mnt/somewhere.

Off the top of my head, it might be a good plan to simply create
symlinks in ~/Trash (or ~/.Trash or ~/Desktop/Trash, whatever)
to .trash directories.

This requires either:

* Mirroring the filesystem hierarchy in ~/Trash
  -> bad

* 'fixing' paths (/mnt/somewhere/trash -> _mnt_somewhere_trash)
  -> bad

* Using unique filenames.
  -> good

Trying this out, I get this:

rik without Trash > ls -l
total 0
lrwxrwxrwx   1 rik [...] abcde -> /x/.trash
lrwxrwxrwx   1 rik [...] fghij -> /home/rik/.trash
lrwxrwxrwx   1 rik [...] klmno -> /tmp/.trash

Hmm, there's always the possibility that $HOME is not writable
by the user, but that's their own stupid fault ;)

Keeping trash in the same location as the deleted file(s) and
references to 'trashcans' in $HOME seems attractive to me.

How does this sound ?

> Other folks suggested that creating directories on volumes other than
> the home volume is "like Microsoft"; I don't really know what that
> means so I can't address that complaint.

I'm not sure what that means either.

Rik





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]