2008/7/4 David Faure <<a href="mailto:dfaure@trolltech.com">dfaure@trolltech.com</a>>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">> It's correct? If it do, I think that the sentence "A relative pathname<br>
> is to be from the directory in which the trash directory resides (i.e.,<br>
> from $XDG_DATA_HOME for the "home trash" directory);" should use a<br>
> example not involving the "home trash" directory. We say that relative<br>
> path names should not be used in "home trash" directory while a moment<br>
> ago we use the "home trash" directory as example to explain the<br>
> meaning of the relative pathnames.<br>
<br>
</div>Yeah. It would be better to say "from the directory in which the<br>
trash directory resides (i.e. from $topdir)"</blockquote><div><br>I think is too easy to interpret the directory where the 'trash directory' resides as the parent directory of the 'trash directory'.<br>
I think that to be unambigous the Spec should at least define the meaning of the term "reside in", but this is not necessary. <br><br>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".<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
> 2)<br>
> The specification does not clearly tell when use the absolute paths and<br>
> when use the relative path. I think this behaviour should be explicitly<br>
> specified.<br>
<br>
</div><br>Yes. Although the above would solve this too.<br>
Home trash -> absolute paths.<br>
Other trash dirs -> relative paths.<br>
This is what I did in the KDE implementation.</blockquote><div> </div><div>I suggest to modify the Spec to add these sentences.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
> 3)<br>
> What happen in the following situation? [...]<br>
><br>
</div><br><div class="Ih2E3d">> The relative path names are relative from the directory which the trash<br>
> directory resides (/mnt/disk1/.Trash/).<br>
> The relative path name is "../foo".<br>
<br>
</div>No no, what this means here is: relative to the $topdir. This is where the trash resides,<br>
globally, without taking into account the small detail of the .Trash/$uid subdir stuff.<br>
The relative path on this partition is "foo".<br>
I agree that this could be misread, but then it doesn't make sense :-)<br>
What makes sense, is to store relative paths from the mountpoint, i.e. from $topdir.</blockquote><div><br>Ok, now it makes sense.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">
> 4) Personal trashcans<br>
> We use the numeric $uid to identify the personal trashcans.<br>
> But, for a usb pen, there is the need to have many personal trashcans?<br>
> The same person could have different $uid on different machines.<br>
> When she/he trash a file containted in the usb pen disk on a system<br>
> he/she expect to found the trashed files in the trashcan even if the<br>
> she/he uses the usb-pen disk on another system (even if in this system<br>
> her/his $uid number is different).<br>
<br>
</div><br>Yes. I think this was discussed during the elaboration of the spec, but I don't<br>
remember what was said exactly. Might be a good idea to read those arguments<br>
first, unless Alexander remembers.<br>
Ah I see a post from him on 06-Feb-2008 about this very problem... I thought I answered<br>
it but it seems I didn't. I'll do so now, quoting it all so you get that post too :)</blockquote><div><br>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. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 5) Interoperability with other Operating Systems. [...]<br>
<div class="Ih2E3d">> I think that the Trash Spec should require (or suggest) to conform to<br>
> the de-facto standard on these filesystems.<br>
<br>
</div>From an implementor point of view I guess it could be interesting to have<br>
pointers to those other specs, even though from a standard specification<br>
point of view it's a bit strange to point people to other (de-facto) standards... ;)</blockquote><div><br>I see, but the thing that I don't like from a user point the following is strange:<br><br>- the user has a dual boot machine<br>
- under linux the user trashes many Gb in the trashcan<br>- some time after the user is using in Windows, and notices that the disk free space is low<br>- the user empties the Windows recicle bin but the free space is still low<br>
<br>The user should knows that there are two different data structure for the trashcan in her/his disk? <br></div></div><br>I think that the Spec should specify that are not recommended to be used on filesystem like VFAT, NTFS, and HFS .<br>
<br>-- <br>Andrea Francia