Problems understanding Trash Spec and problems in Trash Spec itself
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".
> > 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.
> > 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
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
> remember what was said exactly. Might be a good idea to read those
> 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
- 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 .
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg