Problems understanding Trash Spec and problems in Trash Spec itself
andrea.francia at gmx.it
Thu Jul 3 15:32:08 PDT 2008
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
--- begin of the excerpt ---
 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);  it MUST not include a “..” directory, and for files
not “under” that directory, absolute pathnames must be used.  The
system SHOULD only support absolute pathnames in the “home trash”
directory, not in the directories under $topdir.
 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 ---
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
My understand if that because the  the implementation shall not set
the Path as
But, instead it shall set the Path as (for example)
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.
The specification does not clearly tell when use the absolute paths and
when use the relative path. I think this behaviour should be explicitly
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
Now the implementation should choose if use a relative path name or a
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
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
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
For those filesystems there is already a standard for the trashcan data
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
More information about the xdg