[maybe devel/gvfs] Volume icons persist after volumes are unmounted

[grahamperrin]

Partly following on from #9

[probonopd]

I cannot reproduce this using helloSystem build: 0E57 for commit: 80061bf on real hardware.

[grahamperrin]

Installed, or live boot?

[probonopd]

I tested on Live ISO.

[grahamperrin]

Why did you assume that it's a VirtualBox issue without testing an installation?

[probonopd]

Why did you assume that it's a VirtualBox issue without testing an installation?

I don't. I'm just flagging all tickets that only have been reproduced in VirtualBox so far.

Looking at your screenshots, VitualBox is in use. I have started to mark all issues that involve VirtualBox with the [VirtualBox] prefix until the issue has been reproduced on real hardware. Also, looking at your screenshots, the installed system seems to be modified and/or upgraded? For testing, it would be most helpful to test with "factory fresh" builds :)

[grahamperrin]

I wasted hours trying to install helloSystem on real hardware; in chat I described some of the hardware; then you told me to do myself a favour and use real hardware. For testing, it would be most helpful if you stop rushing to false conclusions about VirtualBox.

[probonopd]

I seem to be able to reproduce something that may be related when using the 13 based builds, e.g., helloSystem/ISO#195.

Question: When you are running into this, hat happens after killing Filer by pressing Ctrl+Alt+Esc and clicking on the desktop and then running launch Filer --desktop?

[probonopd]

Volume icons are correctly removed after volumes are unmounted on helloSystem 0.6.0.

Please comment here if the problem persists.

[grahamperrin]

Please comment here if the problem persists.

helloSystem/hello#161 (comment)

icon on the desktop, showing the empty(!) DVD drive.

@probonopd what exactly happens after you double-click the icon?

Given your experience with real hardware, it might be appropriate to remove [VirtualBox] from the subject line.

[probonopd]

As described in helloSystem/hello#161 (comment), I ran various commands to update both FreeBSD itself as well as packages.

When I came back after having shut down the computer, an entirely useless icon appeared on the desktop, showing the empty(!) DVD drive. It was not there before. And one for the SSD, even though that one is mounted using ZFS on / which is shown as "Startvolume" on helloDesktop.

It is this kind of unpleasant surprises that makes part of me think that allowing users to do package-based updates just leads to untestable, random results. Hence my idea to make the whole system one image and leave it at that.

[probonopd]

It would be interesting to know how a freshly installed helloSystem 0.6.0 (installed to hard disk) performs.
Then do just the FrreeBSD update, reboot, see if the problem appears.
Then also do the packages update, reboot, see if rhe problem appears.

This kind of issue exactly proves my point - updating stuff can lead to random breakage that cannot be tested by running the Live ISO.

[probonopd]

Why a thumbs down? It's not that I want it to be that way. It's just that I observe that it is this way.

[probonopd]

Without a disc inserted:

FreeBSD% gio info 'computer:///HL-DT-ST DVD+-RW GH50N.drive' 
Anzeigename: HL-DT-ST DVD+-RW GH50N
Name: HL-DT-ST DVD+-RW GH50N.drive
Typ: mountable
Adresse: computer:///HL-DT-ST%20DVD+-RW%20GH50N.drive
Attribute:
  standard::type: 6
  standard::name: HL-DT-ST DVD+-RW GH50N.drive
  standard::display-name: HL-DT-ST DVD+-RW GH50N
  standard::icon: drive-optical, drive, drive-optical-symbolic, drive-symbolic
  standard::sort-order: -3
  standard::symbolic-icon: drive-optical-symbolic, drive-symbolic, drive-optical, drive
  id::filesystem: computer:
  access::can-write: FALSE
  access::can-delete: FALSE
  access::can-trash: FALSE
  access::can-rename: FALSE
  mountable::can-mount: FALSE
  mountable::can-unmount: FALSE
  mountable::can-eject: TRUE
  mountable::unix-device-file: /dev/cd0
  mountable::can-start: FALSE
  mountable::can-start-degraded: FALSE
  mountable::can-stop: FALSE
  mountable::start-stop-type: 1
  mountable::can-poll: FALSE
  mountable::is-media-check-automatic: TRUE

[grahamperrin]

Suspect a bug in something other than FreeBSD, something other than https://github.com/freebsd/pkg/

The symptom below is vaguely familiar:

Above, what shows content for a drive that's empty? Is it Filer?

[probonopd]

This is absolutely not the fault of pkg. But strangely it was never discovered on the Live ISOs. Why?

I think I never saw computer:///*.drive entries before running the update. If that is the case then it should hopefully be relatively easy to filter them away in Filer. Or maybe there is a config setting somewhere (in gio? gvfs? UDisks2? bsdisks?) to switch the *.drive stuff off again.

What is creating those useless, unwanted computer:///*.drive entries all of a sudden?

gio? gvfs? UDisks2? bsdisks?

Will investigate.

[probonopd]

libfm cannot be it, as we are using a privately bundled one.

[probonopd]

I have the gut feeling that this has to do with it:

FreeBSD% pkg which /usr/local/libexec/gvfsd-computer

/usr/local/libexec/gvfsd-computer was installed by package gvfs-1.46.2

FreeBSD% strings /usr/local/libexec/gvfsd-computer | grep "\.drive"
.drive

But then, the exact same version 1.46.2 we have been shipping on the Live ISO builds where this issue does not manifest itself... at least not in Live mode.

Before the updating, I had gvfs-1.46.1_2 as I can see by booting into that BE.

[probonopd]

Now... after having booted into another Boot Environment and now again into the Boot Environment, the extraneous entries are magically gone. I don't understand this.

This whole gvfs thing is one of the last Red Hat code bases in helloSystem and I think it also needs to go sooner or later as discussed elsewhere.

[grahamperrin]

gone

Similarly,

#65 (comment)

The cd0 icon, and Filer's ghostly view of a file system that was unmounted prior to opening of the window, seem to be symptoms of a bug that is transient (that does not survive a restart of the OS):

#65 (comment)

Volume icons are correctly removed after volumes are unmounted …

Please: was there a related commit, or was that simply an observation of behaviour at the time?

[grahamperrin]

#65 (comment)

… The symptom below is vaguely familiar: …

Found:

lxqt#1279 (comment)

• the device remains in the sidebar after umount
• the path (no longer available) remains in the address bar
• the directory content (no longer available) remains in the window.

[probonopd]

Volume icons are correctly removed after volumes are unmounted on helloSystem 0.6.0.

That was simply an observation by looking at what the Live ISO does.

[grahamperrin]

#65 (comment)

[After running freebsd-update] …

#65 (comment)

… seem to be symptoms of a bug that is transient (that does not survive a restart of the OS): …

Without running freebsd-update(8):

1. logged out from the desktop environment
2. switched to ttyv1
3. pkg upgrade -f
4. shutdown now
5. exit single user mode
6. there's a desktop icon for the empty virtual optical drive, for which Filer presents an error
7. there's a desktop icon for the virtual hard disk, for which Filer presents an error
8. the desktop icon for StartVolume works
9. after closing all windows, reopening the two error-related items has no effect (neither a window, nor an error)
10. reloading the desktop reorders the three items, the two error-related items remain non-openable (neither a window, nor an error):

du -hs /dev/cd0 measures 0B.

https://bsd-hardware.info/?probe=c233ecb213

Output from pkg prime-list:

android-file-transfer-qt5
appmenu-gtk-module
arandr
archivemount
asmctl
automount
avahi-app
b43-fwcutter
ca_root_nss
cpdup
cups-pdf
dmidecode
drm-fbsd12.0-kmod
dsbdriverd
dsbmixer
dunst
eject
falkon-qtonly
featherpad
font-awesome
freedesktop-sound-theme
furybsd-settings
fusefs-ext2
fusefs-hfsfuse
fusefs-ntfs
fusefs-squashfuse
fusefs-unionfs
git-lite
gpu-firmware-kmod
gstreamer1-plugins-good
gstreamer1-plugins-ogg
gstreamer1-plugins-soup
gstreamer1-plugins-vorbis
gvfs
hello
hplip
hw-probe
iichid
initgfx
intel-backlight
kf5-kconfig
kf5-kcoreaddons
kf5-kdbusaddons
kf5-kglobalaccel
kf5-ki18n
kf5-krunner
konsole
libappindicator
libdbusmenu-qt5
libexif
libinput
libsynaptics
libva-intel-driver
localize
lsblk
lximage-qt
lxqt-globalkeys
menu-cache
mesa-dri
mesa-libs
mountarchive
mpv
nano
nss_mdns
openbox-theme
openntpd
pciutils
pkg
pkg-provides
pv
py310-sqlite3
py38-beautifulsoup
py38-dateutil
py38-psutil
py38-pytz
py38-qt5-dbus
py38-qt5-multimedia
py38-qt5-network
py38-qt5-qml
py38-qt5-webengine
py38-qt5-widgets
py38-sqlite3
py38-xdg
py38-xmltodict
pycharm-ce
python3
qpdfview
qt5-graphicaleffects
qt5-l10n
qt5-quickcontrols2
qt5-sensors
qt5-wayland
qtcreator
qtermwidget
redshift
screenkey
setxkbmap
slim
sourcecodepro-ttf
ssvnc
sudo
system-config-printer
tmux
usbids
usbutils
utouch-kmod
virtualbox-ose-additions
webcamd
wget
wpa_supplicant_gui
wqy-fonts
x11vnc
xauth
xcb-util-cursor
xdg-user-dirs
xdg-utils
xdotool
xf86-input-evdev
xf86-input-keyboard
xf86-input-libinput
xf86-input-mouse
xf86-video-ati
xf86-video-cirrus
xf86-video-intel
xf86-video-scfb
xf86-video-vesa
xinit
xinput
xkill
xmodmap
xorg-server
xrdb
zsh

[grahamperrin]

10. reloading the desktop reorders the three items, the two error-related items remain non-openable (neither a window, nor an error): …

11. shutdown -p now
12. started the virtual machine
13. there remained desktop icons for the virtual hard disk and empty virtual optical drive, with errors when opened
14. inserted hello-0.6.0_0F54-FreeBSD-12.2-amd64.iso in the optical drive
15. the desktop icon for the optical drive remained non-usable, reloading the desktop did not resolve the issue
16. geom disk list shows Mediasize: 0 (0B) for cd0.

[probonopd]

I suspect that the gvfs package is causing this. Actually this may be the behavior wanted by the gvfs people (but not by us). So maybe the earlier package gvfs-1.46.1_2 had a bug that prevented those nasty entries from being created, lucky for us. If you are brave, try downgrading to 1.46.1_2 and see if the issue goes away.

[grahamperrin]

https://www.freshports.org/devel/gvfs/#history 1.46.2 was committed 2021-01-23, there's nothing superior.

[probonopd]

Sorry, typo! I meant 1.46.1_2 - correcting above.

Using the magic that is Boot Environments, I redid my update (using the new Update utility!) but this time I ran sudo pkg lock --yes automount slim gvfs dejavu liberation-fonts-ttf beforehand - and the bug is not there.

[probonopd]

Probably this code is responsible:
https://gitlab.gnome.org/GNOME/gvfs/-/blob/master/daemon/gvfsbackendcomputer.c#L490-502

Maybe @ondrejholy knows how to disable the creation of .drive entries entirely.

[probonopd]

In Filer, we have

computerFolder_ = fm_folder_from_path(fm_path_new_for_uri("computer://"));

Apparently this loads everything from computer://. I didn't find a way to filter out .drive entries yet. (We only want .mount entries.) Even worse, I think one (randomly?) either gets .driveentries or .mount entries. I don't understand it.

[ondrejholy]

The computer backend has not been touched for years and is not used by core components anymore. It was designed to show all drives, volumes, and mounts propagated by volume monitors. If you now see .drive entries and they were not shown before, then this is probably some change in volume monitors used in FreeBSD. There are no configuration options for the computer backend.

[probonopd]

Thanks @ondrejholy, very helpful information.

probably some change in volume monitors used in FreeBSD

After some experimentation it turns out that the issue occurs when /usr/local/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service is there. Unfortunately updating the gvfs package in FreeBSD always places this file there, even though we had deleted it before. So this is a FreeBSD packaging topic. Looks like the *.service files should be treated more like configuration files by pkg, so that if one lovingly edits (or deletes) them, they won't be overwritten upon updates.

https://forums.FreeBSD.org/threads/package-upgrade-deletes-config.62805/post-362744 says

Ports/packages never remove or modify configuration files if they have been modified.

Apparently this does not apply to the files in /usr/local/share/dbus-1/services/ unfortunately.

We need to find a way to prevent pkg update from overwriting (or adding) certain files.

[probonopd]

According to crees, the gvfs port would need to install sample files and use @sample in the plist. So: @sample share/dbus1/services/x.sample.

[ondrejholy]

Just a note that the UDisks2VolumeMonitor is the preferred one (at least on Linux) and its removal might affect the functionality of GLib-based applications, not just the computer:// view, but I don't totally have any experience with FreeBSD, nor helloSystem...

[probonopd]

Deleting /usr/local/share/dbus-1/services/org.gtk.vfs.UDisks2VolumeMonitor.service fixed this issue, so closing here.

That a package update in FreeBSD will write it there again is another issue.