Problems understanding Trash Spec and problems in Trash Spec itself

[David Faure]

On Friday 04 July 2008, Andrea Francia wrote:
> 1)
> What is the the meaning of the following sentence?
> 
> - The system SHOULD only support absolute pathnames in the “home trash”
> directory, not in the directories under $topdir.
> 
> What is the meaning of the phrase after the comma? There is a lack of a
> conjunction. 

The conjunction is there: "not" ;-)

> I'm not a native english speaker I'm don't know if the 
> sentence is not clear or is me that is not able to understand it.

I think it's clear: the system should not use absolute pathnames in other partitions,
only relative filenames.

What's not clear to me is the "from the directory in which the 
trash directory resides (i.e., from $XDG_DATA_HOME for the “home trash” 
directory)" part. Who cares about trashing files from XDG_DATA_HOME?
This is a bad example. I agree with you that this part makes no sense.

>     Path=/home/andrea/.local/share/foo
Yes.

> It's correct? If it do, I think that the sentence "A relative pathname
> is to be from the directory in which the trash directory resides (i.e.,
> from $XDG_DATA_HOME for the “home trash” directory);" should use a
> example not involving the "home trash" directory. We say that relative
> path names should not be used in "home trash" directory while a moment
> ago we use the "home trash" directory as example to explain the
> meaning of the relative pathnames.

Yeah. It would be better to say "from the directory in which the 
trash directory resides (i.e. from $topdir)"

> 2)
> The specification does not clearly tell when use the absolute paths and
> when use the relative path. I think this behaviour should be explicitly
> specified.

Yes. Although the above would solve this too. 
Home trash -> absolute paths.
Other trash dirs -> relative paths.
This is what I did in the KDE implementation.

> 3)
> What happen in the following situation? [...]
> 
> The relative path names are relative from the directory which the trash
> directory resides (/mnt/disk1/.Trash/).
> The relative path name is "../foo".

No no, what this means here is: relative to the $topdir. This is where the trash resides,
globally, without taking into account the small detail of the .Trash/$uid subdir stuff.
The relative path on this partition is "foo".
I agree that this could be misread, but then it doesn't make sense :-)
What makes sense, is to store relative paths from the mountpoint, i.e. from $topdir.

> So the implementation record the Path as absolute (/mnt/disk1/foo).

No. Relative is what we want here, obviously.

> 4) Personal trashcans
> We use the numeric $uid to identify the personal trashcans.
> But, for a usb pen, there is the need to have many personal trashcans?
> The same person could have different $uid on different machines.
> When she/he trash a file containted in the usb pen disk on a system
> he/she expect to found the trashed files in the trashcan even if the
> she/he uses the usb-pen disk on another system (even if in this system
> her/his $uid number is different).

Yes. I think this was discussed during the elaboration of the spec, but I don't
remember what was said exactly. Might be a good idea to read those arguments
first, unless Alexander remembers.
Ah I see a post from him on 06-Feb-2008 about this very problem... I thought I answered
it but it seems I didn't. I'll do so now, quoting it all so you get that post too :)

> 5) Interoperability with other Operating Systems. [...]
> I think that the Trash Spec should require (or suggest) to conform to
> the de-facto standard on these filesystems.

From an implementor point of view I guess it could be interesting to have
pointers to those other specs, even though from a standard specification
point of view it's a bit strange to point people to other (de-facto) standards... ;)

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