Re: Trash system

["Oleg Noskov" <olegn corel com>]

Hi there,

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

The reason for having hex here was rather simple - easy parsing of the .info file.
Converting time into a string has advantages for human readability, but parsing it back into
a number format every time just didn't seem right.


>
> > 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 guess mime type is not something that you care about when you move a file into Trash. Why
bother determining mime type when you are trashing something? In the majority of cases
trashed files never get restored anyway. Why take CPU resources to do mostly useless task?
Additionally, mime type information is implementation dependent. After all, there's no one
system-wide MIME registry. KDE uses its own, there's a file on the OS level, even different
applications like Netscape or Apache have their own MIME databases. Since Trash is supposed
to be not limited to one Desktop implementation, having MIME types in there don't look
consistent.


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

What do you store in Trash/tmp?
I have no problem with splitting the .info and files themselves into separate subfolders.
However, compatibility will be broken for sure.

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

In CFM we just generate another random name.

>
> > * open() tmp/<unique name>.
> > * Write metadata, (check retval of each write() call.)

In CFM there's only one trash folder per user. So if you move files to the Trash from
another filesystem (another partition, for example), we do physically move all the file
hierarchy. Therefore, a free space check is done before any file writing occurs. David,
answering your remark about no portable way of checking free space: I guess there is one.
What we do is popen("df","r") and parse the output of df command.

>
> > * 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 :)

I think the biggest stumbling block right now is to agree whether we have a user-specific
Trash in every filesystem or there's only one Trash folder per user.
My opinion is that transparently creating Trash folders on multiple filesystems is bad. What
credentials would be used when you create these directories? If user credentials, then there
might be no writing permissions on that filesystem (except for the folder where the items
being moved to Trash are located). And in general, I don't think it is right to assume that
we can mess any filesystem without explicitly notifying user about such activity. It is too
much like a Microsoft way of doing things. :)

Oleg Noskov
project leader, Corel File Manager
Corel Corp.