Trash Spec Idea

João Valverde backup95 at
Wed Aug 13 12:13:11 PDT 2008


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.

Trashing from a user's home partition works well (except for this nasty 
Gnome bug [1] that has been open for 5 years) but outside that scenario 
things start to break down. In my opinion moving files across partitions 
should never be acceptable.

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. 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.

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...


João V.


More information about the xdg mailing list