Trash spec 0.4

[Alexander Larsson]

On Thu, 2004-09-09 at 12:48 +0200, David Faure wrote:
> 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.

Nah. That one is broken already by ".Trash". I mean a limit on the
length of filenames. I'm not sure what limit for instance VFAT has. But
if its 32 or something like that, adding 10 to it means only filenames
of 22 characters can be used in files/. But some googling seems to
suggest the VFAT limit being 255, so I think its ok with a .trashinfo
extension.

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

Lets keep it. It should be ok. 

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

Ah, yes. Sorry.

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

So, you resolve the symlinks. That does make it work.
Take this example for instance:
 fs mounted on /mnt/md1
 /opt/foo -> /mnt/md1/i386-foo
 trashing /opt/foo/file.

The trashdir would be /mnt/md1/.Trash/$uid/.
And the info file would contain "i386-foo/file".
It does sort of leak the symlink abstraction into a user file. Although
i guess that is right. If you untrash it on a machine where /opt/foo
points to /mnt/md1/i686-foo you do want it back in i386-foo, not i686-
foo.

The spec should perhaps mention something about fully resolving the
symlink before generating the relative pathname.

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

So, what if I run in the utf8 locale, but have an old file with an
iso-8859-1 encoded filename? Or I somehow got a file with a kio8-r
filename from some tarball i unpacked? Given just a filename on the
filesystem to trash, how am I supposed to know what encoding to put in
the Encoding field?

And, even if I somehow magically knew the filename was in kio8-r, say it
was "/opt/<kio8-r string>/file". If I save the encoding as kio8-r in the
trashinfo file, then KDE will know how to read this file and convert the
name to unicode. When "untrashing" it'll try to restore it to "/opt/<you
locale string>/file", but "/opt/<your locale string>" doesn't exist, so
it fails.

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

Well. The way i read the current spec was:
do {
  make up filename
  stat(filename)
} while (not ENOENT);
open(filename, O_CREATE)

which isn't right, since it has a race condition.

> > This also means the implementations *MUST* create the info files first.
> 
> Yes - I think this is in the spec already.

Its listed as "SHOULD", not "MUST".

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an otherworldly pirate vagrant searching for his wife's true killer. 
She's a wealthy winged queen of the dead married to the Mob. They fight crime!