<div dir="ltr">2008/8/13 João Valverde <span dir="ltr"><<a href="mailto:backup95@netcabo.pt" target="_blank">backup95@netcabo.pt</a>></span><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;"> Hello,<br> <br> I was looking into doing a bash command line trash implementation as a<br> beginner's exercise but I quickly realized it would be much hairier than<br> I thought at first.  Besides some inherent complexity from the file<br> system hierarchy and permissions I think the spec has some shortcomings<br> and from browsing the archive I see that they have been discussed here.</blockquote><div><br>I created a similar program. A command line interface written in python for the trash can.<br>The website is <a href="http://code.google.com/p/trash-cli/" target="_blank">http://code.google.com/p/trash-cli/</a><br> <br>May be we can collaborate.<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;">...</blockquote><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> What I am missing right now is an efficient way to locate all $topdir's<br> that support trashing when trying to list the trashcan contents. It's<br> possible to parse mtab and go from there but I don't really care to do<br> that frankly.<br> <br> I think another approach is needed. This information needs to be<br> centralized somewhere.</blockquote><div><br>These information are already centralized somewhere: in the kernel memory.<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;"> My suggestion is (following the spirit of the<br> current spec) to create some metadata *.trashcan files in<br> $XDG_DATA_HOME/Trash that would describe every other partition's<br> trashcan, obviously containing the full path and maybe with some size<br> limits and auto cleanup settings as a bonus. If the trashcan partition<br> is not mounted, it can be silently ignored. It's not a perfect solution<br> because this has the potential to generate a lot of stale metadata for<br> removable media, as it's difficult to remove these files automatically<br> when unmounting volumes but maybe an expiry time could be used in that<br> case (or better yet disable trashing for removable media).<br> <br> These would either be created and configured by an administrator or by<br> implementations when opening trashcans.</blockquote><div><br>The $XDG_DATA_HOME directory is a per user directory. <br>With this approach the administrator should access to the directory of each user. <br>This is not a centralized solution. <br>  </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Is this feasible? Better than going through mtab right? How else could I<br> find mount points for trash folders? How much can be done automatically<br> when mounting or unmounting volumes? Are there any plans to involve HAL<br> on this? My ignorance starts to show here...</blockquote><div><br>The component that knows the informations about the mount points is the kernel. <br>There's no need to duplicate these informations in $XDG_DATA_HOME with the risk that those are inaccurate or non synchronized.<br><br>The kernel communicates the status of the current mount points with /etc/mtab and (in some systems) with /proc/mounts.<br><br>To parse the /etc/mtab (or the /proc/mounts) file you should use getmnt(2) system function that recognizes all the special cases  (like spaces in mount points) that and a reinvented parser may not consider.<br><br></div></div>-- <br>Andrea Francia<br><a href="http://andreafrancia.blogspot.com/" target="_blank">http://andreafrancia.blogspot.com/</a><br> </div>