Trash spec 0.4

[David Faure]

On Thursday 09 September 2004 10:08, Alexander Larsson wrote:
> > The $trash/info directory contains an information file for
> > every file and directory in $trash/files. This file MUST have exactly
> > the same name as the file or directory in $trash/files, plus the
> > extension .trashinfo. 
> 
> I'm not sure about this. Adding 10 characters to the filename makes it
> very likely to not fit in the filename length limit on many filesystems.

Since you're talking about filename limit rather than full-path limit,
I assume this is about the MSDOS 8.3 limit? Do we really still care about that one?
IIRC there's another filesystem with a limit but I can't remember which one.

> Do we really need the extension for this? 

I thought we decided on it so that all info files are seen as having the
same mimetype. This is not _very_ important, it's just in case the user
opens the info dir - better have well-defined mimetypes for files when
we can. The extension is just a fast way to have that, faster than
"detection from the contents".
But if you think it will create trouble on some filesystems, I'm ok with 
removing the extension, the speedup was for a rare case indeed.

> > The system SHOULD only support absolute pathnames in the home
> > trash directory, not in the directories under $topdir. 
> 
> Why is this? 

The idea was to avoid "trojan devices" which would be able to have
fake trashed files which, when restored, would overwrite files in another partition.
E.g. a /mnt/floppy/.Trash/$uid/info/foo.txt could contain Path=/home/someone/.profile,
and restoring foo would try to overwrite the user's .profile...

> There are many cases where the relative pathname without 
> ".." will not allow you to express all files on the mountpoint.

I don't see how, since we're talking about the toplevel dir of
the mountpoint as the base - everything in this mountpoint is under it.

> A common situation is if you have the fs mounted somewhere and use
> symlinks into it. Say, filesystem on /mnt/hda2. Symlinks from /opt
> to /mnt/hda2/opt. The trashdir would be /mnt/hda2/opt/.Trash
Would it? If the filesystem is /mnt/hda2, then the trash dir is
/mnt/hda2/.Trash, not /mnt/hda2/opt/.Trash, since it has to be at
the toplevel of the partition.

And then you store "opt/filename" in the info files (located in /mnt/hda2/.Trash/$uid/info/),
and they refer correctly to the files on the hda2 partition. If moving stuff around
to another partition, one would have to only move the relevant parts of the trash
though (opt/* but not the rest). Sounds like a job for some sysadmin 
command-line tools; unless people take the opportunity of moving stuff around
for also cleaning their trashcan :)

> Maybe its a network filesystem mounted in
> different places on different machines. 

Relative paths allow this, but for the trash to be shared one would have to mount
the whole partition on the other machine, not just a subdir. If a subdir, then
the trash isn't shared (e.g. /mnt/hda2/.Trash isn't part of the shared "opt" dir)

> > The value type for this key is localestring it should use
> > the locale in which file names are stored on this file systems, or, if
> > this is unknown, UTF-8. 
> 
> This is wrong, and cannot work. The encoding of a filename is
> unknowable, and the locale for a file might differ between users,
> sessions, etc. You also cannot convert a pathname to a different
> encoding and expect it to work! If you change the name of one of the
> directories to utf8 from say latin-1, you will put the file back in a
> different place!
> 
> No, filenames are raw byte-stings without the slash character or the
> zero byte, containing the exact bytes of the original filename. Anything
> else will break. How to display the filename (i.e. convert it to
> unicode) is up to the desktop, and each implementation already has code
> to do this for normal files.

I agree to what you say, but I don't really see a contradiction with what Mikhail
wrote (except for the utf8 fallback). OK the fallback doesn't make sense,
since we currently always know which encoding to use for filenames (even
though in kde we assume it's the same everywhere).
Well this is opening a whole can of worms currently since Qt/KDE doesn't do
this right for systems with multiple encodings, since we convert everything
to Unicode. No need to explain to me at length why this is wrong, I know it is,
bu that's how it is currently. So let's use the Encoding field like in the 
desktop entry spec, to define what's the encoding used in the trashinfo file,
otherwise we'll never be able to guess what to use.
Currently KDE always uses UTF-8 when generating .desktop files (and trashinfo files),
but at least with an explicit encoding we'll have less interoperability problems
(if the trashinfo file contains a kio8-r path, the encoding will say so, and everyone
will be able to read it correctly).
Basically this is just like .desktop files with an Exec line; let's not invent another solution.

> The right algorithm is:
> 
> 1. Make up a name you haven't tried before
> 2. open (filename, O_CREAT|O_EXCL, mode)
I used O_WRONLY too.

> 3. if the open failed with EEXIST, there was already a file with that
> name. Goto 1.
> 4. Now you have a filedescriptor to a file that is atomically guaranteed
> to not have existed before. (Or, the open failed for another reason,
> such as out of space.)
> 5. Write the trashinfo file to the filedescriptor.
> 6. We're now guaranteed there is no file with the same name in the files
> subdir, so move the trashed file there.

OK, good, that's what I implemented. I think Mikhail simply hinted at
"use O_EXCL as usual", without attempting to actually define a full algorithm.

> This also means the implementations *MUST* create the info files first.

Yes - I think this is in the spec already.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).