Re: Trash system

[David Faure <david mandrakesoft com>]

On Thursday 14 December 2000 17:26, you wrote:
> #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

Why does that matter at all ?
We just want a unique identifier, random. The info file contains
all the info we need.

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

Since you didn't the ones who used this format in cfm, I'm not sure you'll
get an answer.... Cc'ing.

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

Yes, although applying the usual mimetype-determination procedure
on the file (which remains intact, as you can see in this solution),
would give the same result.

> 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

Good idea.
It would break the CFM compatibility, but that's unavoidable when setting up a standard.

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

Note that we have KTempFile and KSaveFile in KDE for that,
they do exactly that :)

-- 
David FAURE, david mandrakesoft com, faure kde org
http://www.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today