Trash Spec Idea
andrea.francia at gmx.it
Wed Aug 13 13:31:00 PDT 2008
2008/8/13 João Valverde <backup95 at netcabo.pt>
> 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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg