Trash Spec Idea

[Andrea Francia]

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

Regards

-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/07/colinux-linux-dentro-windows.html