Trash Spec Idea

[Andrea Francia]

2008/8/13 João Valverde <backup95 at netcabo.pt>

> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20080813/2bc5e892/attachment.htm