GIO is part of GLib.
And GIO is not a part of GTK.
The base OS and GLib version are unlikely to matter: it’s more likely your code being wrong.
@ebassi ,
Well, I tried to run the same code you guys were running but from Python interpreter.
And my code is very simple:
GioVolumeMonitor *monitor = g_volume_monitor_get();
GList *volumelist = g_volume_monitor_get_mounts( monitor );
This is the code I tried to debug in the gdb session above.
As you can see I successfully obtained the monitor pointer, but get_mounts() call failed to get the list. Just like in that Python script.
BTW, I don’t know how you guys structured, but I presumed that Gio have its own maintainer as part of the GLib umbrella. Thank you for correction.
Thank you.
The thing about mounts and drive information is that, while the code you call from GLib might be quite simple, there are multiple different compile-time alternatives within GLib (gunixmounts.c) determining how mounts are parsed, and then there are several different files on your system which could provide mount information (/proc/self/mounts, /proc/self/mountinfo, /etc/fstab, /etc/mtab) — and all of those will differ from what’s on someone else’s system.
So unfortunately there’s relatively little chance that someone else will be able to debug this for you, regardless of whether they’re a maintainer of GIO. It’s too system-dependent. Sorry. I’ve given you all the hints I can think of — the next step I’d do, if I were debugging this, would literally be to step through the code and work out how the system mount information is being pulled into GIO and outputted again.
@pwithnall ,
I understand, thx.
I was actually hoping that the library can just query the actual OS or do what the “mount” command do…
That’s OK. I’ll see what I can find…
Thank you.
1 Like
That’s basically what it does, except there’s extra logic in there to:
- Ignore ‘system’ mounts (ones which wouldn’t make sense to show in a file chooser dialog) in some situations
- Try and work out which mount points are drives and which mounts are volumes related to those drives
@pwithnall ,
OK, thx. Will check.
@pwithnall ,
OK, mystery solved. 
igor@WaylandGnome ~ $ cat /etc/fstab
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed); notail increases performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail / tail freely.
#
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# See the manpage fstab(5) for more information.
#
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
#
# NOTE: Even though we list ext4 as the type here, it will work with ext2/ext3
# filesystems. This just tells the kernel to use the ext4 driver.
#
# NOTE: You can use full paths to devices like /dev/sda3, but it is often
# more reliable to use filesystem labels or UUIDs. See your filesystem
# documentation for details on setting a label. To obtain the UUID, use
# the blkid(8) command.
/dev/sda1 /boot vfat noauto,noatime,comment=x-gvfs-show 1 2
/dev/sda3 / ext4 noatime,comment=x-gvfs-show 0 1
/dev/sda2 none swap sw,comment=x-gvfs-show 0 0
/dev/cdrom /mnt/cdrom auto noauto,ro,comment=x-gvfs-show 0 0
igor@WaylandGnome ~ $
I added the “comment=x-gvfs-show” parameter in /etc/fstab and now the script works correctly:
igor@WaylandGnome ~ $ python
Python 3.11.8 (main, Mar 24 2024, 02:40:39) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> from gi.repository import Gio
>>> volume_monitor = Gio.VolumeMonitor.get()
>>> print(f'Number of drives: {len(volume_monitor.get_connected_drives())}')
Number of drives: 1
>>> print(f'Number of drives: {len(volume_monitor.get_volumes())}')
Number of drives: 2
>>> print(f'Number of drives: {len(volume_monitor.get_mounts())}')
Number of drives: 1
>>>
It would of course be nice to know why number of volumes is not equal to number of connected drives, but I can live with that for now…
Bug thx goes to “netfab” from Gentoo forum (ref. Gentoo Forums :: View topic - GIO failure in C++ but runs perfectly from Terminal)
Maybe those 2 need “show_hidden” parameter?
And it also could explain the difference in behavior between Emmanuele and jakedane.
Thank you.
I think I know what happens here:
I have a shadow mount somewhere…
Thank you,
Now I consider this topic solved.
However I have the follow-up question.
What is the policy on this forum?
Should I continue here or make another thread?
Thank you.
The option x-gvfs-show suffices, prefixing it with comment= is redundant.
But anyway, that led me to find this commit which explains that x-gvfs-show is used to force it to show if the logic would otherwise hide it. I think the guess_system_internal () has the clues for why volumes/mounts are hidden. If you look up the functions g_unix_is_system_fs_type (), g_unix_is_system_device_path () and
g_unix_is_mount_path_system_internal () it calls in the same file, you can see lists of the things it hides. The last one for example hides / and /boot.
I can’t find where in the gio code it handles the x-gvfs-show option but in the gvfs code it does so in should_include (). The gio code must use the gvfs code somewhere I guess.
I think it boils down to I/we went into it with incorrect expectations. The expectation that g_volume_monitor_get_connected_drives (), g_volume_monitor_get_volumes () and g_volume_monitor_get_mounts () show all connected drives and volumes (partitions) and mounts on them. Instead it hides what it considers to be “system internal”. The point to that hiding, I take it, is that this also determines what Nautilus for example shows under Other Locations. If you add x-gvfs-show to a mount in /etc/fstab it will now also show that under Other Locations (and with GNOME 47 I think will show it in the sidebar). Not desired behavior for / and /boot for example.
That said I now understand why my / and /boot are not shown but I have a separate disk with a single ext4 partition mounted to /games and I can’t figure out why gio is hiding that one unless I add x-gvfs-show.
I updated the script to show some details for volumes and mounts:
#!/usr/bin/python3
import gi
from gi.repository import Gio
volume_monitor = Gio.VolumeMonitor.get()
print(f'Number of drives: {len(volume_monitor.get_connected_drives())}')
for drive in volume_monitor.get_connected_drives():
identifier = drive.get_identifier(Gio.DRIVE_IDENTIFIER_KIND_UNIX_DEVICE)
name = drive.get_name()
print(f' {identifier}: {name}')
print(f'Number of volumes: {len(volume_monitor.get_volumes())}')
for volume in volume_monitor.get_volumes():
identifier = volume.get_identifier(Gio.DRIVE_IDENTIFIER_KIND_UNIX_DEVICE)
name = volume.get_name()
drive_id = volume.get_drive().get_identifier(Gio.DRIVE_IDENTIFIER_KIND_UNIX_DEVICE)
print(f' {identifier}: {name} (drive: {drive_id})')
print(f'Number of mounts: {len(volume_monitor.get_mounts())}')
for mount in volume_monitor.get_mounts():
root = mount.get_root().get_path()
name = mount.get_name()
volume_id = mount.get_volume().get_identifier(Gio.DRIVE_IDENTIFIER_KIND_UNIX_DEVICE)
print(f' {root}: {name} (volume: {volume_id})')
So if for my software I need to write a tree-like Files control, I’m out of luck?
Because I will not be able to retrieve the root folder/icon…
And ofc, it would be interesting why ebassi can successfully execute even the old script while you can’t.
Thank you.
And ofc it doesn’t answer the question of why?
If your follow-up question is very highly related to the questions so far (e.g. covered by the same topic title), then continue in this thread. Otherwise please open a new topic, thanks.
You should be able to do this by using the underlying Gio.unix_mounts_get() API rather than GVolumeMonitor (which is documented as being “for listing the user interesting devices and volumes on the computer. In other words, what a file selector or file manager would show in a sidebar.”).
I’ve just found the check which hides non-interesting devices from GVolumeMonitor here: gio/gunixmount.c · main · GNOME / GLib · GitLab
1 Like
Thank you for that.
Is thwere a function like Gio.unix_volumes_get(), to do the same for volumes?
Thx.
New thread made here: Properly delete GList and identifying the mount point drive (follow-up)
Quickly searching for ‘mount volume’ in the API reference finds g_mount_get_volume(). There is also g_drive_get_volumes() and g_volume_get_drive() and g_mount_get_drive() for finding those relationships.
@pwithnall ,
OK, will check,
Thx.
The page at Gio.UnixMountEntry, does not list any APIs.
Does this mean that I can use the same calls as for GMount and no new things is available?
And the classes are interchangeable/castable?
Thank you.
Through a quirk of history, the methods for GUnixMountEntry all have prefix g_unix_mount_ rather than g_unix_mount_entry_.
@pwithnall ,
What version of Glib/Gio this function is available from?
Trying to compile the code I get:
error: ‘g_unix_mounts_get’ was not declared in this scope; did you mean ‘g_unix_fd_list_get’?
23 | volumelist = g_unix_mounts_get( nullptr );
| ^~~~~~~~~~~~~~~~~
| g_unix_fd_list_get
Or maybe it became part of public API recently-ish?
Surprisingly I can call it from Python:
igor@WaylandGnome ~/wxFork $ python
Python 3.11.8 (main, Mar 24 2024, 02:40:39) [GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import gi
>>> from gi.repository import Gio
>>> print(f'Number of drives: {len(Gio.unix_mounts_get())}')
Number of drives: 2
>>>
So, since it worked from python, I looked it up.
Apparently gio.h is not enough. I need to include gio/gunixmounts/h
Thank you.
BTW, the comment in the linked commit says:
/* No volume for mount: Ignore internal things */
I’d understand the removal of /dev, /proc, /swap, but hiding “/” as internal?
I would relax this check and remove only the system mounts, but that’s unfortunately not up to me… And its too late anyway