GNOME Bugzilla – Bug 663603
Any mount point should be excludable in the preferences
Last modified: 2021-05-26 09:26:51 UTC
This issue has already been raised in the more specific report: https://bugzilla.gnome.org/show_bug.cgi?id=330471 But the issue is more general than bind mounts as the comments there suggest. Encfs/encryptfs/NFS/CIFS mounts are also affected. Any active mount point should be excludable (possibly via preferences).
The new UI list volumes in the "main page" and the preference dialog to exclude locations is gone, so I am closing this. Thanks for your feedback
I'm currently using 3.4.1 and indeed there is no way to exclude any paths. Yet both the search via volumes and the search via directories will count the contents of encfs-mounted directories both for the encrypted and decrypted paths. These mount points are not listed as volumes. I understand that it can both make sense to find out how much space the encrypted file system is using and how much the decrypted files would be using if they were saved dircetly on disk. But adding them together does not make sense. If these mount points cannot be detected automatically I believe that being able to omit specific paths is an important feature. Yet I will leave it to the maintainers to change the status of this report as it makes little sense to keep this open if a patch to re-add these preferences would be rejected.
Ok I will reopen and think about a way to expose this in the UI... suggestions are welcome, but I would like to avoid a prefs dialog. Also note that with "new UI" I meant the upcoming 3.6 that features a completely renewed user interface
I believe most expectations would be met, if the list of volumes contained all mount points (including fuse, loop, bind mounts). And all active mount point paths should be excluded for all volumes, except the matching volume. I'm not sure what the correct way of determining the mount points is. How are the list of volumes determined? There may be a similar API for mount points. How does the "mount" command determine the active mounts? Simply by parsing /etc/mtab? If that's the case then maybe that's what boabab should do. A little research indicates that this the boabab uses libgtop so it would be interesting what mount points are returned by: http://developer.gnome.org/libgtop/stable/libgtop-mountlist.html I'll try to write a little tool to see if fuse mount points are listed via this API, as soon as I find the time.
Crazy idea for Paolo: maybe an indented/treeview-style "start page" (the one where you pick which device/folder to scan) with checkboxes that allow unchecking mountpoints within a given device/folder/etc.?
Created attachment 310965 [details] [review] Exclude mounts when scanning recent locations Mount points are excluded for all other cases and locations from file chooser exclude them by default also. I think we should exclude them for recent locations to be consistent.
Created attachment 310966 [details] [review] Remember scanner flags for recent locations Location list really needs focus of some designer, however I think the best what we can do without UI changes is remember scanner flags for recent locations. Recursive scanning of mount points can be allowed from the file chooser dialog, but the scanner flags are not restored when you scan recent location next time after baobab exited. Use metadata database to store scanner flags.
Review of attachment 310966 [details] [review]: The two patches should probably be squeezed? Anyway, it seems a good idea to remember the scan flag, but maybe we should show it in the UI? Otherwise it would be a bit unpredictable. Not sure how, though, maybe an emblem on top of the icon, or a label...
(In reply to Stefano Facchini from comment #8) > Review of attachment 310966 [details] [review] [review]: > > The two patches should probably be squeezed? I wanted to push the fix before the 3.18 release (so I wanted to avoid UI and string changes). The reason I used two patches is that I think it is better to push at least the first patch to be baobab behavior consistent in all other cases... don't you think? > Anyway, it seems a good idea to remember the scan flag, but maybe we should > show it in the UI? Otherwise it would be a bit unpredictable. Not sure how, > though, maybe an emblem on top of the icon, or a label... We can squeeze those patches if you like the second approach. But I am afraid I don't have in mind any suitable emblem, which would be self-descriptive enough. So new strings are needed probably and we have to postpone it for 3.20... :-/
Comment on attachment 310965 [details] [review] Exclude mounts when scanning recent locations Ok let's go with this for now, we'll look into a more complete solution for next cycle. Attachment 310965 [details] pushed as 89748a4 - Exclude mounts when scanning recent locations
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of Baobab, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/baobab/-/issues/ Thank you for your understanding and your help.