Re: Trash system

[rik kde org]

#if Oleg Noskov
> 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.

It's not storing it as a number that I'm questioning, just the fact
it's stored in hex rather than denary :) I know strtol can cope
with this, but for us it's easier to have it in denary so that
we can do QString("12345").toInt(). QString doesn't handle hex.
 
> 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?

Because when you browse your trash to find files, you might want to sort
them by type - or just see the type, of course. When you don't have the
mime type already available while moving to trash, just don't write it
to the metadata. Types can also be written to the metadata later, if the
user browses the trash.

> 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 think putting a mimetype string "type/subtype" in the info file is
portable enough. It's fairly standard to specify the mime type of
a file this way, no ?

The basic idea is that when we move a file to trash, we may already have
the mime type of that file. So if we store it in the metadata, we avoid
a stat(). It's just caching.

We shouldn't waste any disk space with this because metadata files will
usually be less than the size of an inode and writing e.g. "text/plain"
should not tip the size over the limit.

The longest path names I have are about 150 chars, which I'd guess is
fairly average. Add up all the data, and I don't think it'll be over
1024 bytes in most cases.

> What do you store in Trash/tmp?

The info file, as you're writing it. If you store it in the directory it
will be found in, then it may be read before you have finished writing
it.

> I have no problem with splitting the .info and files themselves into
> separate subfolders.  However, compatibility will be broken for sure.

I'm sorry about that, but we need to think about safety and efficiency.
readdir() will take twice as long if you put all info and 'deleted'
files in the same directory.

> > > * While stat() does not return ENOENT, wait 2s, increment sequence
> > > number.
> 
> In CFM we just generate another random name.

That'll do.

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

Determining if you have run out of space is not the only reason to
check the retval of write(). NFS outage can occur.

Using df to check available space is an evil hack because the space
can change while you're writing. 

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

Agreed.

Rik