Re: Trash system

[rik kde org]

#if David Faure
> - "Move To Trash" menu item appears in the CFM. When it is invoked, a
> new trash entry is created for every item moved. First, the unique
> 9-character name is generated (starting with dot, then 8 random characters, 
> then checked for non-duplicated entry). Then a directory with that name 
> is created in ~/Desktop/Trash, and the file or folder in question is moved 
> into that directory. Then ".info" is appended to the name
> above and file with that name is created in ~/Desktop/Trash.

Why 8 random characters ? That seems like a random decision :)

How about a unique string, e.g.

timeAtProcessStart + '.' + pid + '.' + sequence++ + '.' + hostname

For my machine, you'd get entries like this:

976813742.123.456.without

> This file has the following structure:
>     <original location>
>     <date deleted in hex>

Why hex ?

>     <File size>
>     <File mode>
>     <mtime of the original file in hex>
>     <ctime of the original file in hex>

Why hex ?

If you're going to store this info, perhaps adding mime info would
be a good idea. I presume storing the size is to avoid having to
stat each file when browsing. So storing the mime type would help
us too.

I'd also suggest that for safety over NFS, NFS-style writing is
used. If metadata is lost, we'll have users getting upset.

Also, storing dotfiles (being the 'deleted' files) and '.info' files
will cause efficiency problems when you read a large trash directory.

Therefore, I would suggest the following:

Structure:

Trash/tmp
Trash/info
Trash/files

When a process wishes to move a file to trash, it follows these
steps:

* chdir() to the Trash directory.
* stat() tmp/<unique name>.
* While stat() does not return ENOENT, wait 2s, increment sequence number.
* open() tmp/<unique name>.
* Write metadata, (check retval of each write() call.)
* Call fsync() (and check retval !)
* Call close() (and check retval !)
* rename() the file to be deleted as files/<unique name>.
* rename() the metadata file as info/<unique name>.

I think this should avoid problems with NFS and system crashes. It
should also be reasonably efficient.

Rik