3

I'm currently writing a basic filesystem abstraction (in C++) and I need to get a list of "useful" mounted devices on linux.

I've found the function(s) getmntent/getmntent_r that allow to me to easily parse /etc/mtab and /proc/mounts however many of the mounted devices aren't "useful" (such as: /sys/fs/cgroup/net_cls). In particular I'm attempting to find mounts which related to a physical device, partition or network share/drive.

The closest I've found is checking if the mnt_fsname (device name) starts with a /, which in the case of my system narrows it down to:

  • /

  • /boot

  • /run/media/[username]/0CA8-1F2D

  • /run/media/[username]/14E0-3E80

Which appears to be what I want (the latter two being partitions on a usb stick). I haven't had a chance to try out a network share/device with it though.

Basically this is meant to be an approximation of windows-like 'drives', hence why I'm interested in physical devices etc., but doesn't prevent a library user navigating to unlisted devices if they so-desire.

So basically the question boils down too:

  • If the device name in a mount entry starts with a / is it guarenteed to be a physical device, partition or network share?

  • Will I be leaving out anything particularly important/useful?

  • Is there a better/more precise way to do this?

  • how about something akin to?: df -x tmpfs -x devtmpfs – Theophrastus Jul 29 '16 at 17:23
  • /proc is not a physical device, partition, or network share, so it is not guaranteed. Trying to implement windows 'drives' on linux sounds like a half-baked plan to begin with, since the linux way is a ton more flexible. Why exactly are you trying to do this? – Wyatt8740 Jul 29 '16 at 17:29
  • @Wyatt8740 I can gather devices from multiple sources other than just /proc so that's a non-issue. I'm not so much as trying to implement windows 'drives' on linux, all I'm doing is providing 'system-agnostic' shortcuts to physical drives, paritions and network shares for ease of use. If the library user wants to navigate to a particular directory/device, they're not prevented from doing so. – LivePastTheEnd Jul 29 '16 at 17:41
  • @Theophrastus Actually that works beautifully. I'll need to figure out someway to use it a bit cleaner though, executing another program and parsing the output is a little clumbersome but not that big a problem - that and it adds another dependancy. But I'll see if I can wrap my head around the source. – LivePastTheEnd Jul 29 '16 at 17:44
  • Note that recent windows versions also permit mounting to directories. – Wyatt8740 Jul 29 '16 at 17:47
1

I don't think there's a notion of “useful mounts” that makes sense in all scenarios. You want to include removable physical drives and network mounts, and exclude filesystems for system access such as those under /dev, /proc and /sys. What about filesystems mounted by the user? Knowing that a filesystem is provided by FUSE doesn't tell you what it is. It could be an archive, a network mount, an alternate view of a directory, a disk image, a way to control some program, …

Checking if the device name starts with / doesn't seem useful to me. For example it would include bind mounts and exclude network mounts.

I think the best you can do is to not reinvent the wheel. If nothing else, by using the same mechanism as others, you won't confuse your users (“why does X list that filesystem but not Y???”). Additionally there's a chance that what the others did might make sense.

So my recommendation is to use Gnome libraries, at least GTK+. GTK+ has a file opening dialog which shows some mounted filesystems under “Places”. Users can control what is listed there to some extent — if they can figure it out, that is. Even if you don't show the file open dialog from GTK+, use the same list of “places” (I don't know how to obtain that, look at the API documentation).

  • Actually that's pretty much perfect. Looking at the second link I believe I should be able to implement something that behaves identically and atleast while it's not a universal standard it's a flexible standard nonetheless! – LivePastTheEnd Jul 30 '16 at 4:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.