Problems understanding Trash Spec and problems in Trash Spec itself

[Andrea Francia]

 From the numbered version of the Trash Spec
(http://andreafrancia.it/trash/numbered-trashspec.html, the numered
version is the same but it is unofficial and contains a number near each
requirement).

--- begin of the excerpt ---
[280] It also must have two lines that are key/value pairs as described 
in the Desktop Entry Specification:

     * The key “Path” contains the original location of the 
file/directory, as either an absolute pathname (starting with the slash 
character “/”) or a relative pathname (starting with any other 
character). 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); [290] it MUST not include a “..” directory, and for files 
not “under” that directory, absolute pathnames must be used. [300] The 
system SHOULD only support absolute pathnames in the “home trash” 
directory, not in the directories under $topdir.

       [310] The value type for this key is “string”; it should store 
the file name as the sequence of bytes produced by the file system, with 
characters escaped as in URLs (as defined by RFC 2396, section 2).

--- end of the excerpt ---

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

What happen if I ask the implementation to trash the file/dir in this
location $XDG_DATA_HOME/foo?
My understand if that because the [300] the implementation shall not set
the Path as

    Path=foo

But, instead it shall set the Path as (for example)

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

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.

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.

3)
What happen in the following situation?

The system mounts a disk on /mnt/disk1.
Someone had created teh /mnt/disk1/.Trash directory setting the sticky bit.
The user want to remove the file located at /mnt/disk1/foo, so she/he
tell to the implementation to trash it.
The implemementation succesfully creates the trash directory as
/mnt/disk1/.Trash/$uid:

    /mnt/disk1/.Trash/$uid/
    /mnt/disk1/.Trash/$uid/files
    /mnt/disk1/.Trash/$uid/info

Now the implementation should choose if use a relative path name or a
absolute one.
The relative path names are relative from the directory which the trash
directory resides (/mnt/disk1/.Trash/).
The relative path name is "../foo".
But a relative path name SHALL not be used because cotains ".." (see
requirement 290).
So the implementation record the Path as absolute (/mnt/disk1/foo).

The disk is umounted from /mnt/disk1, and it is mounted on another mount
point /mnt/disk2.
The user ask to recover the trashed file in the original location but
the implementations, cause of the absolute path, tries to recover in
/mnt/disk2/foo instead of in /mnt/disk1 as expected.

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

Some filesystem does not take care of user numerid identifier.
Why should we put this information in it?
Why not use a trash directory ($topdir/.Trash/) common for all users in
the filesystem that does not take care of the numeric $uid?.

5) Interoperability with other Operating Systems.
There is a interoperability issue because filesystems like VFAT, NTFS
could be shared (through the usb-drives or through the dual boot) with
other operating systems that uses a different data structure for the
trashcan directory.

For those filesystems there is already a standard for the trashcan data
structure.
The same could be applied to the filesystems used by other O.S. having a
standard for the trashcan data structure (I think the Mac).

I think that the Trash Spec should require (or suggest) to conform to
the de-facto standard on these filesystems.

I know that there is at least two diffent trashcan data structure used
by the MS Windows operating systems.
There is one that does not record information about the user and it is
used on VFAT.
And there is another that record user information and it is used on NTFS
filesystems.

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html