Bug#836355: libglib2.0-0: makes all entries of fstab show up as desktop items

Simon McVittie smcv at debian.org
Sun Jun 9 00:22:57 BST 2019 

On Fri, 02 Sep 2016 at 06:42:19 +0200, Adam Borowski wrote:
> After today's upgrade of libglib2.0-0, I get every single entry of fstab,
> even /proc, show up as a desktop item.  This is with xfce.
> 
> Reproducible on a freshly installed system; you just get 2 entries
> ("Filesystem root" and "cdrom0") as fresh fstab is rather empty.
> 
> No gvfs installed, so none of those should show up.

It appears that gvfs *not* being installed is a key part of this, at
least in buster. This probably indicates that this is a limitation of
the fallback GUnixVolumeMonitor in GLib, which is used when a better
plugin (like gvfs' GVfsUDisks2VolumeMonitor) is not present or has been
disabled.

GLib and gvfs are separate components to avoid circular dependencies
(for instance if gvfs was integrated into GLib, then udisks2 couldn't
use GLib without a circular dependency) but for desktop use-cases,
I'm fairly sure their overlapping sets of upstream maintainers would say
that GUnixVolumeMonitor is only intended as a fallback implementation,
and is not designed to have the full UI heuristics.

File managers (and implementations of icons on the desktop, if separate)
should probably have a Depends, Recommends or Suggests on gvfs to indicate
this. XFCE's thunar Recommends gvfs and doesn't mention gvfs-backends,
which seems appropriate for a desktop environment intended to be
lightweight; GNOME's nautilus Depends on gvfs and Recommends the more
elaborate gvfs-backends, which seems appropriate for a more fully-featured
desktop.

Perhps libglib2.0-0 should also have a Suggests on gvfs (and
glib-networking, which has a similar role for TLS and network proxy
support), but since that would be circular, I'd be concerned that
it might prevent apt frontends from proposing libglib2.0-0 and gvfs
for autoremoval when the last package that depends on them is removed.
A Recommends definitely seems too strong, because GVolumeMonitor is only
a small part of GLib.

If you don't want the more complicated gvfs backends, like the ones for
network protocols and MTP devices, I would suggest installing gvfs and
its required gvfs-daemons package, but not installing gvfs-backends.

Steps to reproduce:

- Install amd64 virtual machine from buster d-i RC 1 netinst, with
  XFCE selected in tasksel. I used the virtio SCSI device type to try to
  make the VM a bit more like real hardware (and to get discard support),
  and chose the installation option with a separate /home, /tmp and /var
  to try to make the bug more obvious.

- Log in to XFCE. Result: no extraneous desktop icons. I forgot to note
  down exactly what I had, but I think it was Wastebasket, File System
  and Home.

- Run the attached list-mounts.py (you will need python3-gi, because I
  didn't want to use C as a prototyping language, but in practice the
  buster XFCE task installs that by default anyway). The output I got
  is in with-gvfs.json. This lists various sorts of object which might
  indicate what it is that XFCE is displaying, and their properties.

- Purge gvfs.

- Log out. Log in as root on a tty, and `pkill -u user` (where my ordinary
  user account was called "user") to make sure no stale user processes
  have lingered.

- Log back in to XFCE as the ordinary user. Result: desktop has:
  - Filesystem root
  - File System (redundant)
  - Home (this is the user's home directory, /home/user)
  - home (this is the directory containing homes, /home)
  - cdrom0 (translucent to indicate a CD is not inserted)
  - tmp
  - var

- Re-run list-mounts.py. The output I got is in without-gvfs.json.

- Reinstall gvfs.

- Repeat the log out, kill user processes, log in cycle.
  Result: desktop has:
  - Wastebasket
  - File System
  - Home

- Re-run list-mounts.py. The output I got is in with-gvfs-again.json
  (it seems to be the same as with-gvfs.json, but in a different order).

- Also try "GIO_USE_VOLUME_MONITOR=unix python3 list-mounts.py", which
  forces the GUnixVolumeMonitor to be used (this environment variable was
  originally intended for debugging, but is also used by system services,
  unit tests, gvfs itself, etc. if they want to use GIO without using D-Bus
  or gvfs services). The output I got here is in with-gvfs-disabled.json.

Some comments from my results:

- gvfs can list drives (via udisks2). The fallback GUnixVolumeMonitor
  can't: in the freedesktop.org stack, that's udisks2's job, but GLib
  can't depend on udisks2 without it being circular.

- gvfs filters out "uninteresting" system mounts and doesn't include them
  in the lists of GMount objects. The fallback GUnixVolumeMonitor
  doesn't have that heuristic. In principle it could use things like
  g_unix_is_mount_path_system_internal(), but that feature request would
  probably be considered "won't fix" upstream, since desktops are meant
  to use gvfs anyway.

- It looks as though the fallback GUnixVolumeMonitor populates the list of
  volumes (GVolume objects, representing mountable disk-like devices)
  from a lower-level API that is basically /etc/fstab, and again doesn't
  have many heuristics to filter out "uninteresting" entries.

- It looks as though whichever XFCE component draws the desktop (possibly
  thunar but I don't know XFCE well) always adds an icon for File System,
  which seems reasonable to do. It would perhaps be a reasonable wishlist
  bug against that component to say that it should ignore a GMount with
  root "/" (if any), which is always redundant with File System. However,
  the maintainer of that XFCE component might reasonably say that using
  it without gvfs isn't intended to be supported.

- The unix_mounts and unix_mount_points lists in the list-mounts.py
  output are a lower-level, Unix-specific GLib API layer. Looking at
  their source code, it doesn't seem to be used directly by either
  nautilus or thunar (but gvfs does use it behind the scenes, so if you
  or any other bug reporters are having trouble with gvfs showing devices
  that it shouldn't, this information will be useful).

If this doesn't match your experience, please could you try running
list-mounts.py on an affected system and see what it says? This should
hopefully help to pin down which layer the problem is in.

I've only tested list-mounts.py on buster. It should mostly still work
with older GLib releases, but you might have to comment out calls to
any methods that don't exist in the older release.

Thanks,
    Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: list-mounts.py
Type: text/x-python
Size: 4835 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/695392ae/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with-gvfs.json
Type: application/json
Size: 33504 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/695392ae/attachment-0004.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: without-gvfs.json
Type: application/json
Size: 37328 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/695392ae/attachment-0005.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with-gvfs-again.json
Type: application/json
Size: 33504 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/695392ae/attachment-0006.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: with-gvfs-disabled.json
Type: application/json
Size: 37328 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20190609/695392ae/attachment-0007.json>

More information about the pkg-gnome-maintainers mailing list