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