Trash Spec Idea
andrea at andreafrancia.it
Fri Aug 15 04:11:22 PDT 2008
João Valverde wrote:
> Andrea Francia wrote:
>> There are a lot of filesystems out there and it seems futile to
>> keep track of every single one. One possibility is writing a
>> parser in C
>> that compares the filesystems in /proc/filesystems (I assume "nodev"
>> means it's a virtual filesystem?) against /etc/mtab and returns the
>> mount points that have the correct type.
>> Are you sure that all filesystems with nodev are fake filesystems?
> Pretty sure... Again, there are probably weird exceptions out there. I
> don't know about FUSE though. Is it relevant for trash purposes? I
> really don't know... I see that gvfs-fuse-daemon uses the type
> "fuse.gvfs-fuse-daemon" in /etc/mtab and that doesn't match any entry
> in /proc/filesystems.
The "cifs" filesystem is marked "nodev" in /proc/filesystems, I think
the TrashCan should works also on this filesystem. I wonder if also the
'nfs' has the nodev attribute
I think that there's no correlation with 'nodev' attribute and the
suitability of have the Trash Can.
>> If you rely on /proc/filesystems your program will work only on those
>> system that have the /proc filesystem available.
> But it should still work on all Unix-like systems. It's not so
> different than depending on /etc/mtab.
Not all unix-like systems supports a /proc filesystem. In any case, even
if it is supported, it may be not activated.
I don't see the rationale of introducing such dependency.
>> I think that the blacklist alternative is better.
>> At the present trash-cli doesn't have yet a black-list, simply checks
>> if the .Trash directory exists. This works for me.
>> If you don't have a /net fileststem the blacklist will only speed up
>> the list-trash operation of few milliseconds, I'll implement that
>> only after other things.
> I have to disagree there. You're hard coding something that can be
> provided dynamically by the kernel.
Kernel can not provide the suitability of have Trash Can in a particuarl
I don't think that there is problems in 'embedding' (or hardconding) in
a program some knoweldge. The list of suitable filesystem is not likely
to be changed by the user.
If in a early revision the list is hardcoded there is no problem to make
it configurable in a future version.
I don't think this is the priority because the program still work well
checking if the .Trash directory exists.
> I wrote some basic proof of concept type code and it seems to work
> well. It prints to stdout all the mount points associated with device
> nodes. Even as a command line tool maybe it could fill a legitimate
> need if improved. I'm attaching it in case anyone is interested, I
> hope that's OK.
Sure I'll read it.
Thanks for your opinions, especially because are different of mine. This
help me to understand the problem.
More information about the xdg