Re: Trash system
- From: rik kde org
- To: gnome-kde-list gnome org, olegn corel com
- Subject: Re: Trash system
- Date: Fri, 15 Dec 2000 00:47:57 +0000
#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]