MountPoints changed signal needs to nul-terminate mountpoint names
If a file is open on the drive as it's unmounted, gvfs calls "lsof -t /mountpoint" to find processes which have files open in that mountpoint, and then sends the "show-processes" signal to the file manager, which shows a dialog with those processes and "Cancel" / "Eject anyway" buttons.
With bsdisks, that process list is often empty, for 2 reasons:
- lsof (sysutils/lsof) never supported msdosfs on FreeBSD, and cd9660 regressed in FreeBSD 7.
- "lsof -t" is often called by gvfs without a mountpoint specified.
I got (1) fixed with a patch to lsof on https://github.com/lsof-org/lsof/pull/151, but even with this in place, (2) remained a problem. With extensive debugging and comparing against Linux, I eventually figured that one out as well.
On Linux the MountPoints changed signal sends nul-terminated mountpoint names. When I hack bsdisks to do the same, the process list is always shown.
This works, but there might be ways to do it better, maybe by pre-populating nul-terminated mountpoints in the mountPoints variable from the start instead of nul-terminating them just before sending, or keeping a nicer QString list if the conversion has to be done just before sending:
diff -r 77c83bdf501a blockfilesystem.cpp
--- a/blockfilesystem.cpp Thu Feb 25 09:00:37 2021 +0300
+++ b/blockfilesystem.cpp Sat Mar 13 11:46:21 2021 +0200
@@ -265,7 +265,12 @@
void BlockFilesystem::signalMountPointsChanged()
{
QVariantMap props;
- props.insert(QStringLiteral("MountPoints"), QVariant::fromValue(mountPoints));
+QByteArrayList mps;
+for(auto mp = mountPoints.begin(); mp != mountPoints.end(); mp++)
+{
+ mps << (*mp + '\0');
+}
+ props.insert(QStringLiteral("MountPoints"), QVariant::fromValue(mps /*mountPoints*/));
QDBusMessage signal = QDBusMessage::createSignal(
parentBlock()->dbusPath.path(),
I am very happy with bsdisks otherwise. It never crashes any more. It is so correct and reliable that the remaining bugs I am discovering are in lsof, the kernel, gvfs (https://gitlab.gnome.org/GNOME/gvfs/-/merge_requests/118) and Thunar (https://gitlab.xfce.org/xfce/thunar/-/issues/516). There are still some cosmetic issues, like different looking drive icons, and possible new features, like support for loop devices, encrypted volumes, swap space, etc., but those are minor issues affecting special interests. When can you make the next release?