GLib issueshttps://gitlab.gnome.org/GNOME/glib/-/issues2021-01-22T21:10:31Zhttps://gitlab.gnome.org/GNOME/glib/-/issues/2294trashed content visible even for volumes not supporting trashing2021-01-22T21:10:31Zbrainchildtrashed content visible even for volumes not supporting trashingIssue #2153, under *Remarks*, features the comment:
> Also note that file managers using GIO still find content previously trashed on the same volumes for which they will no longer trash new content. This conflations strikes me as confu...Issue #2153, under *Remarks*, features the comment:
> Also note that file managers using GIO still find content previously trashed on the same volumes for which they will no longer trash new content. This conflations strikes me as confusing and likely to lead to new problems.
In other words, the criteria for a volume into which may be placed new trashed content is less inclusive than the criteria for a volume in which may be viewed content already trashed.
I am opening a separate issue to address this problem.https://gitlab.gnome.org/GNOME/glib/-/issues/2230Export optical drive types2022-07-14T10:41:58ZBastien NoceraExport optical drive typesThere's currently no way to list all the drives that handle a particular type of media, without resorting to hacks like (without memory management):
```
gicon = g_drive_get_icon (gd);
if (!gicon)
return ret;
if (!G_I...There's currently no way to list all the drives that handle a particular type of media, without resorting to hacks like (without memory management):
```
gicon = g_drive_get_icon (gd);
if (!gicon)
return ret;
if (!G_IS_THEMED_ICON (icon))
return ret;
g_object_get (icon, "names", &names, NULL);
ret = g_strv_contains (names, "drive-optical");
```
Once a disc is inserted, and is mounted, one can check the tree content-type, but not before it's mounted, something which might not be automatic in non-GNOME desktops.
Ideally, gvfs would export that information which is available through udisks already:
```
$ gdbus introspect --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/drives/HL_DT_ST_DVD_ROM_DUE0N_KZHI8G84454 | grep MediaCompatibility
readonly as MediaCompatibility = ['optical_cd', 'optical_dvd'];
```
and it's also available on Windows:
- https://github.com/HandBrake/HandBrake/blob/master/gtk/src/callbacks.c#L4913-L4921
- https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdrivetypea#return-value
(This is a bit like #241, but narrower)
@oholy what do you think?https://gitlab.gnome.org/GNOME/glib/-/issues/3141"unmounted" signal not firing as expected2023-10-16T06:58:58ZJakub Janků"unmounted" signal not firing as expectedI get a `GMount` object using `g_file_find_enclosing_mount()` and subscribe to the `"unmounted"` signal (it's a WebDAV mount, but I suppose that that's irrelevant). The callback does not fire unless I get a `GVolumeMonitor` using `g_volu...I get a `GMount` object using `g_file_find_enclosing_mount()` and subscribe to the `"unmounted"` signal (it's a WebDAV mount, but I suppose that that's irrelevant). The callback does not fire unless I get a `GVolumeMonitor` using `g_volume_monitor_get()` first.
Is such behaviour intentional? If so, is it mentioned in the docs somewhere?
I haven't tested it with other mount types, so I'm not sure whether it's a matter of gvfs or gio in general.https://gitlab.gnome.org/GNOME/glib/-/issues/2103Nautilus shows bind mounts as ejectable drives unless mount option x-gvfs-hid...2020-05-25T08:50:30ZPeter OliverNautilus shows bind mounts as ejectable drives unless mount option x-gvfs-hide is usedOn Linux, create a bind mount by adding the following line to `/etc/fstab`:
```
/some/existing/directory /mountpoint none bind
```
Nautilus will show this directory as a removable drive and include an eject button. Such mounts are not...On Linux, create a bind mount by adding the following line to `/etc/fstab`:
```
/some/existing/directory /mountpoint none bind
```
Nautilus will show this directory as a removable drive and include an eject button. Such mounts are not actually ejectable, and clicking the button results in an error message saying that root access would be required.
As discussed in issue #1271, a workaround is to set up the mount like this:
```
/some/existing/directory /mountpoint none bind,x-gvfs-hide
```https://gitlab.gnome.org/GNOME/glib/-/issues/1885trash is not working on mounted btrfs subvol (internal system mounts message)2024-03-27T10:30:32ZJohn Hendytrash is not working on mounted btrfs subvol (internal system mounts message)Greetings,
Maybe related:
- https://gitlab.gnome.org/GNOME/glib/issues/1727
- https://gitlab.gnome.org/GNOME/glib/issues/1024
It looks like the issue might be related to [this commit](https://gitlab.gnome.org/GNOME/glib/commit/d1...Greetings,
Maybe related:
- https://gitlab.gnome.org/GNOME/glib/issues/1727
- https://gitlab.gnome.org/GNOME/glib/issues/1024
It looks like the issue might be related to [this commit](https://gitlab.gnome.org/GNOME/glib/commit/d1eaf72c001279aa15a2135a0749ef864c8edb42). There was an [arch bug](https://bugs.archlinux.org/task/60137) filed (closed as upstream) and at least [a couple](https://bbs.archlinux.org/viewtopic.php?id=241785) of [forum posts](https://bbs.archlinux.org/viewtopic.php?id=248120) on the same issue.
I want to open this for a fundamental and practical inquiry.
1) Fundamental: I don't understand [listing /mnt and /media](https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gunixmounts.c#L223) as not relevant to the casual user. I see loads of tutorials suggesting /media/foo and /mnt/bar as reasonable mount points. Granted, I don't know the full implications of that
function and what else relies on it, but deciding that a user can't trash files from one of these locations seems... odd. Maybe the others, sure, but I think /mnt and /media are fair game, assuming the right permissions exist. And for my use-case, I'm not prevented from deleting, just trashing. So doing this for "protection" doesn't seem to make sense.
2) Practical: why is this happening?
Background on my system, running arch linux. Trash works fine in ~, but was forcing full on deletion for /mnt/vault, symlinked to ~/vault.
```
# fdisk -l
Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 1050623 1048576 512M EFI System /boot/efi)
/dev/nvme1n1p2 1050624 3147775 2097152 1G Linux filesystem /boot)
/dev/nvme1n1p3 3147776 488397134 485249359 231.4G Linux filesystem cryptsetup root, formatted btrfs
$ mount
/dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 on / type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache,subvolid=266,subvol=/arch)
/dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 on /home/jwhendy type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache,subvolid=267,subvol=/jwhendy)
/dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 on /mnt/vault type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache,subvolid=268,subvol=/vault)
$ ls -l /mnt
drwxr-xr-x 1 jwhendy jwhendy 114 Jul 31 14:02 vault
$ ls -la /mnt/vault
drwxrwxrwt 1 jwhendy jwhendy 34 Jul 31 13:52 .Trash-1000
$ id
uid=1000(jwhendy) gid=1000(jwhendy) groups=1000(jwhendy),54(lock),973(realtime),987(uucp),991(lp),993(input),995(audio),998(wheel)
$ pacman -Ss gvfs
extra/gvfs 1.40.2-1 (gnome) [installed]
Virtual filesystem implementation for GIO
```
Once I found the system internal error, I tried this and don't understand.
```
$ cd ~
$ sudo umount /mnt/vault
$ rm ./vault
$ mkdir ./vault
$ sudo mount -o subvol=vault /dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 ./vault
$ touch home-dir-test.txt
$ gio trash ./home-dir-test.txt # shows up in ~/.local/share/Trash
$ touch ./vault/vault-test.txt
$ gio trash ./vault/vault-test.txt
gio: file:///home/jwhendy/vault/vault-test.txt: Trashing on system internal mounts is not supported
$ mount
/dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 on /home/jwhendy type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache,subvolid=267,subvol=/jwhendy)
/dev/mapper/luks-dc2c470e-ec77-43df-bbe8-110c678785c2 on /home/jwhendy/vault type btrfs (rw,relatime,compress=lzo,ssd,discard,space_cache,subvolid=268,subvol=/vault)
```
What's going on here? If It were just an issue with `/mnt`, I'd have changed my mountpoint and gone on with life, but it seems something else is awry.
For what it's worth, someone suggested dolphin, which I tried. It trashes from `/mnt/vault/foo.txt` to `~/.local/share/Trash` with no issues.https://gitlab.gnome.org/GNOME/glib/-/issues/1707Don’t require a GVolumeMonitor reference to use GMount/GVolume/GDrive2019-03-04T16:54:03ZPhilip WithnallDon’t require a GVolumeMonitor reference to use GMount/GVolume/GDriveFollowing on from #1458, it seems that there needs to be a `GVolumeMonitor` instance alive in order for any `GMount`/`GVolume`/`GDrive` behaviour to be correct.
This is not documented, and requires people to know about internal GLib beh...Following on from #1458, it seems that there needs to be a `GVolumeMonitor` instance alive in order for any `GMount`/`GVolume`/`GDrive` behaviour to be correct.
This is not documented, and requires people to know about internal GLib behaviour in order to make their applications behave correctly, which is a leak of implementation details.
We should either:
1. Internally hold a `GUnixVolumeMonitor` reference from `GUnixMount`/`GUnixDrive`/`GUnixVolume` in order to get mtab updates for them.
2. Always have a `GVolumeMonitor` running in the GLib worker thread.https://gitlab.gnome.org/GNOME/glib/-/issues/1024g_unix_mounts_get() ignores btrfs subvolumes2019-09-03T21:30:59ZBugzillag_unix_mounts_get() ignores btrfs subvolumes## Submitted by Matthias Clasen `@matthiasc`
**[Link to original bug (#747540)](https://bugzilla.gnome.org/show_bug.cgi?id=747540)**
## Description
Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1209989
g_unix_m...## Submitted by Matthias Clasen `@matthiasc`
**[Link to original bug (#747540)](https://bugzilla.gnome.org/show_bug.cgi?id=747540)**
## Description
Originally filed here: https://bugzilla.redhat.com/show_bug.cgi?id=1209989
g_unix_mounts_get() ignores btrfs subvolumes
This causes some misbehaviors like nautilus or 'gvfs-ls trash://' fails to list
trashed files. (e.g. http://askubuntu.com/questions/537055/ )
I think the culprit is the following portion of _g_get_unix_mounts() from
gio/gunixmounts.c:
```c
/* ignore any mnt_fsname that is repeated and begins with a '/'
*
* We do this to avoid being fooled by --bind mounts, since
* these have the same device as the location they bind to.
* It's not an ideal solution to the problem, but it's likely that
* the most important mountpoint is first and the --bind ones after
* that aren't as important. So it should work.
*
* The '/' is to handle procfs, tmpfs and other no device mounts.
*/
if (mntent->mnt_fsname != NULL &&
mntent->mnt_fsname[0] == '/' &&
g_hash_table_lookup (mounts_hash, mntent->mnt_fsname))
continue;
```
https://git.gnome.org/browse/glib/tree/gio/gunixmounts.c#n392
The code is not aware of the btrfs subvolumes.https://gitlab.gnome.org/GNOME/glib/-/issues/738g_mount_get_icon() does not always return correct icon2018-07-05T11:18:25ZBugzillag_mount_get_icon() does not always return correct icon## Submitted by Kip
**[Link to original bug (#705166)](https://bugzilla.gnome.org/show_bug.cgi?id=705166)**
## Description
I've consulted with the folks at xdg@lists.freedesktop.org and determined that apparently there is a way to p...## Submitted by Kip
**[Link to original bug (#705166)](https://bugzilla.gnome.org/show_bug.cgi?id=705166)**
## Description
I've consulted with the folks at xdg@lists.freedesktop.org and determined that apparently there is a way to provide a custom icon on mounted volumes in a fd.o friendly way. Mikkel on unity-devel informed me that most desktop environments are probably using glib's g_mount_get_icon() to retrieve this icon. However, I haven't really found a desktop environment that this works properly on so far. This may be because g_mount_get_icon() is used correctly, but not actually returning the correct icon when a custom one was provided.
Using a custom icon on a mounted volume can apparently be done in a fd.o friendly manner by providing a ".directory" file (note only an extension and no leading file name) in the root of the mounted volume. This is a standard Desktop Entry file with the Icon field set to some icon and probably with Type=Directory set.
If the problem is just with g_mount_get_icon(), then theoretically patching this GIO function should enable all desktop environments dependent on it to use the custom icon (e.g. Unity, Gnome, Xfce, etc.).https://gitlab.gnome.org/GNOME/glib/-/issues/235Remount operation2019-08-31T13:56:04ZBugzillaRemount operation## Submitted by Tomas Bzatek
**[Link to original bug (#590007)](https://bugzilla.gnome.org/show_bug.cgi?id=590007)**
## Description
The GIO subsystem was designed to allow authentication only during mount operation (i.e. only one pl...## Submitted by Tomas Bzatek
**[Link to original bug (#590007)](https://bugzilla.gnome.org/show_bug.cgi?id=590007)**
## Description
The GIO subsystem was designed to allow authentication only during mount operation (i.e. only one place with clear result mounted/not-mounted). Once a resource is mounted, it's not possible to re-authenticate or remount (modify) the mount in any other way.
Now imagine you have an ACL-enabled resource where every folder can have different permissions and/or is possible (from backend side) to do re-authenticate as a different user.
One common use case is WebDAV, based on HTTP authentication. Auth request can come on first write attempt, thus undetectable during mount (first read operation). This breaks gnome-user-share usability when password protection is only set for writing.
So we were thinking about several ways to work around this issue with as little API changes as possible and came up with this solution:
- introduce new G_IO_ERROR_NEEDS_REMOUNT
- introduce new g_file_remount () with arguments similar to g_file_mount_mountable () or g_file_mount_enclosing_volume (), i.e. passing GMountOperation instance to handle new auth request.
If unhandled, G_IO_ERROR_NEEDS_REMOUNT would just mean G_IO_ERROR_PERMISSION_DENIED, only giving a hint that remount/re-authentication is possible. We can set some nice verbose error message too. Applications should handle this error similarly to G_IO_ERROR_NOT_MOUNTED, only calling g_file_remount (). Looking at Nautilus code, it should not be difficult to support this feature.https://gitlab.gnome.org/GNOME/glib/-/issues/231no way to find out if mounting the same volume multiple times2021-05-26T16:29:40ZBugzillano way to find out if mounting the same volume multiple times## Submitted by Olivier Sessink
**[Link to original bug (#588705)](https://bugzilla.gnome.org/show_bug.cgi?id=588705)**
## Description
In bluefish there is code that opens files async, and if NOT_MOUNTED is received, mounts the encl...## Submitted by Olivier Sessink
**[Link to original bug (#588705)](https://bugzilla.gnome.org/show_bug.cgi?id=588705)**
## Description
In bluefish there is code that opens files async, and if NOT_MOUNTED is received, mounts the enclosing volumes async.
if authentication is required this pops up a dialog. If multiple files are loaded simultaneously, the user gets multiple authentication dialogs.
I would like to add a check in Bluefish if this volume is being mounted already. After a discussion on #nautilus nobody had a nice way to do this, and Benjamin Otte suggested to file a bug about this.
`<Company>` i'd say it's a bug in gvfs that we should fix somehow
`<Oli747>` not sure this is a bug
it would be nice if GVFS had an error G_IO_ERROR_BEING_MOUNTED
it is my code in bluefish that fires the mount request on the NOT_MOUNTED error
`<Company>` yeah still
`<Oli747>` so you can see it as a bug in bluefish too, I simply shouldn't write code that mounts the same thing multiple times ;-)(
`<Company>` it makes absolutely no sense to pop up 2 dialogs
it'd only be a bluefish bug if you could know you're mounting the same thing
`<Oli747>` well,the popup is also the Bluefish gtk_mount_blabla
object
`<Company>` GtkMountOperation, yeah
`<Oli747>` yeah that one
exactly: so I'm hoping to find a smart way to check that
`<Company>` file a bug about it
that's alex code, he'll know what the best solution is
Version: 2.16.xhttps://gitlab.gnome.org/GNOME/glib/-/issues/161Missing g_mount_set_name2019-08-31T13:56:03ZBugzillaMissing g_mount_set_name## Submitted by Bastien Nocera `@hadess`
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#550585)](https://bugzilla.gnome.org/show_bug.cgi?id=550585)**
## Description
It would be nice if Rhythmbox, or other CD ...## Submitted by Bastien Nocera `@hadess`
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#550585)](https://bugzilla.gnome.org/show_bug.cgi?id=550585)**
## Description
It would be nice if Rhythmbox, or other CD apps such as sound-juicer, were able to set the name of an audio CD.https://gitlab.gnome.org/GNOME/glib/-/issues/140new GMount method g_mount_get_type() / Hibernating network mounts2018-07-05T11:17:40ZBugzillanew GMount method g_mount_get_type() / Hibernating network mounts## Submitted by Norbert Frese
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#533226)](https://bugzilla.gnome.org/show_bug.cgi?id=533226)**
## Description
In KIO-GIOBridge i got the problem that i need to filt...## Submitted by Norbert Frese
Assigned to **Alexander Larsson `@alexl`**
**[Link to original bug (#533226)](https://bugzilla.gnome.org/show_bug.cgi?id=533226)**
## Description
In KIO-GIOBridge i got the problem that i need to filter out the gvfs network mounts in order to list them in the UI (as the native mounts are handled by Solid already). At the moment this is achieved by checking if g_mount_get_root() is not file: protocol, which is not very reliable of course. A better categorization of the GMounts listed by GVolumeMonitor would help...
Perhaps this would help in GNOME too, to avoid the duplicate listing of remote locations in the bookmarks- and the mounts section of the side-pane. Although i believe "hibernating" network mounts as bookmarks is not a good solution anyway. A "virtual-fstab" solution like in libfusi http://www.scheinwelt.at/~norbertf/devel/fusi/ might be preferable - also to store other mount options, which can't be in the URI.Alexander LarssonAlexander Larsson