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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
