Problems understanding Trash Spec and problems in Trash Spec itself

Andrea Francia andrea.francia at gmx.it
Fri Jul 4 11:23:28 PDT 2008


2008/7/4 David Faure <dfaure at trolltech.com>:

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


I think is too easy to interpret the directory where the 'trash directory'
resides as the parent directory of the 'trash directory'.
I think that to be unambigous the Spec should at least define the meaning of
the term "reside in", but this is not necessary.

I suggest to remove the "from the directory in which the trash directory
resides" and simply say that "the relative path are from the $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.


I suggest to modify the Spec to add these sentences.

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


Ok, now it makes sense.


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


I think that the Spec would be better if those design decision justification
are inserted in the Spec, or collected in a companion document, instead to
be left them unorganized in the xdg mailing list archive.


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


I see, but the thing that I don't like from a user point the following is
strange:

- the user has a dual boot machine
- under linux the user trashes many Gb in the trashcan
- some time after the user is using in Windows, and notices that the disk
free space is low
- the user empties the Windows recicle bin but the free space is still low

The user should knows that there are two different data structure for the
trashcan in her/his disk?

I think that the Spec should specify that are not recommended to be used on
filesystem like VFAT, NTFS, and HFS .

-- 
Andrea Francia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20080704/0a5aa959/attachment.html 


More information about the xdg mailing list