Created attachment 52102 [details] Enumerate Mac disks and mounts Version: unspecified (using KDE 4.4.1) OS: OS X Filelight needs to know about mounts for two reasons: 1. Enforcement of scans not crossing filesystem boundaries. 2. Listing the current disks on the startup summaryWidget, so the user can select a disk to scan. Currently #1 uses getfsent() and getmnent(), while #2 uses Solid. None of these methods works on a typical Mac OS X system. Reproducible: Always Steps to Reproduce: 1. Launch Filelight. Observe startup window listing of disks which may be scanned. 2a. Open the preferences, ensure that "Scan across filesystem boundaries" is deselected. 2b. Scan a directory which contains mountpoints, such as "/Volumes" on OS X. Actual Results: 1. The list of disks which may be scanned is empty. 2. The files inside the mountpoints, on a different filesystem, are scanned. Expected Results: 1. Local disks are listed. 2. Files on different filesystems are omitted from the scan. The attached patch uses getmntinfo() to discover mounts on OS X. It also uses QFileIconProvider to get appropriate icons for the disks. Currently the patch will only work on OS X, it should be wrapped in an #ifdef. Unfortunately my cmake-fu is lacking :(
This should be fixed in Solid instead, that's kind of the point of solid. :-) Reassigning.
Is Solid supposed to be able to enumerate mountpoints, even if they're not associated with physical devices? If we want to avoid crossing filesystem boundaries, this should include loop mounts and sshfs and such.
Created attachment 63316 [details] Patch update for kdeutils 4.7.0
Ok, so I think enumerating mountpoints with Solid on OS X probably should actually be feasible. The data needed for StorageAccess and StorageVolume unfortunately isn't available in IOKit, so we'd need a fair bit of new code. One possibility is a new Solid backend using getmntinfo(3), which only looks at mounts and not unmounted disks, but has the advantage of working on the other BSDs. Any BSD folks need/want to collaborate on that? Otherwise, we could presumably use the very under-documented DiskArbitration framework together with the iokit Solid backend. I wish I had a better idea of how to implement things in Solid backends, it's still very fuzzy for me. Either way, both getmntinfo(3) and DiskArbitration framework allow us to ask "is this volume local or remote?" directly. Filelight currently does this by checking the filesystem type against a list of known types, which is rather silly. Is there a way to expose isLocal() or something in Solid?
Ok, I put together an initial implementation of Block, StorageVolume and StorageAccess for the IOKit backend: https://github.com/vasi/kdelibs/commits/iokit-storagevolume I've tested it as much as I could. It compiles on Mac OS X 10.5 and later. So far it works ok with all of: - Internal partitions - Disk images - Removable USB disks - Optical disks - Disks with special characters in their names - Disks using Apple's RAID - Disks using FileVault 2 - Disks partitioned with GPT, APM and MBR partitioning schemes Some notes, especially in areas where I'd like advice: 1. I'm confused about when a StorageVolume should and should not support StorageAccess. Some backends make them identical, some don't. Any guideline? 2. The new device types need DiskArbitration info, so I added DiskArb properties as a new field in just those types. Should I have instead merged DiskArb properties into the existing properties? I'd like to access DiskArb properties from IOKitDevice::icon(), but that looks really difficult the way things are now. 3. TODO: Mounts that aren't block devices, like SMB or MacFuse mounts, aren't exposed in IOKit. The fstab backend already has some support for getmntinfo(), so I'll look into making it work on OS X. 4. TODO: When DiskArb claims a disk isn't 'mountable', it can sometimes still be mounted at the command-line, and currently we don't detect that. This should be fixable by scanning all mountpoints. 5. TODO: Under-implemented properties: - StorageAccess::setup() and teardown() are unimplemented, but shouldn't be hard to do. - StorageVolume::usage() could be improved, and encryptedContainerUdi() implemented, but it's more complicated, I'd have to walk the IORegistry. - isIgnored() is harder to implement, I see no good API to determine whether a partition should be hidden. I could match against a blacklist of partition types. It's also unclear whether statfs's MNT_DONTBROWSE should cause isIgnored() to become true. - Emitting the StorageAccess signals would require a whole pile of extra code to monitor for changes. I'm uninclined to do this, but I might. 6. Wishlist: The Solid API currently only allows devices to have theme-icons. It would be great if there was a way to expose the OS X custom icons that people give their disks. Thanks for taking a look :)
So it looks like Solid currently only exposes NetworkShares that aren't listed in the fstab file, on all platforms. Network mounts manually created at the command-line, for example, are completely unreported. This is clearly non-optimal for Filelight, since it will cross such mountpoints when scanning. Is Solid's behaviour as intended? If so, Filelight should probably be using KMountPoint instead.
This bug is reported on libsolid which is the kdelibs4 version of the solid library. It is now in maintenance mode. If you think it should still be fixed in the KDE Frameworks 5 version of solid please move it to or report a bug on frameworks-solid.
Hello! Sorry to be the bearer of bad news, but this project has been unmaintained for many years so I am closing this bug. Please try again with the latest version and submit a new bug to frameworks-solid if your issue persists. Thank you!