Consider using DFileManager

[probonopd]

Now that @moochris got DFilemanager to compile on FreeBSD we can start to consider it for helloSystem.

Looking at the remaining issues:

It seems like DFilemanager is relying on KDE Solid framework and/or UDisks for managing disks.

kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.UnknownObject" 
 "No such object path '/org/freedesktop/UDisks2/block_devices'"
kf.solid.backends.udisks2: Failed enumerating UDisks2 objects: "org.freedesktop.DBus.Error.UnknownObject" 
 "No such object path '/org/freedesktop/UDisks2/drives'"
(...)
QDBusConnection: name 'org.freedesktop.UDisks2' had owner '' but we thought it was ':1.12'
(...)
unsupported url QUrl("")
unsupported url QUrl("")
unsupported url QUrl("")
unsupported url QUrl("")

Possibly we have the following options, more investigation is needed:

1. Use the Solid framework from KDE (it is in FreeBSD: kf5-solid KF5 hardware integration and detection) - what would this involve? (Before we start doing anything: Does it work in KDE Plasma on FreeBSD?)
2. Use bsdisks as a UDisks2 implementation (it is in FreeBSD: bsdisks UDisks2 service implementation for FreeBSD - in fact I do see bsdisks[2170]: "Registering /org/freedesktop/UDisks2/block_devices/da0p4" in /var/log/bsdisks.log) - or would the above already take care of this
3. Use neither (let the FreeBSD automounter handle disk mounting, as we currently are already doing with Filer)

Intuitively, I would be in favor of the last option because

• It works for Filer
• It is most simple
• It probably requires the least amount of new code
• It is the FreeBSD way of doing things
• It does not draw in new dependencies

As for whether we should use DFilemanager instead of Filer, I am thinking about

• Can we make DFilemanager discover (using Zeroconf) and access (e.g., with ssh://) network devices? Filer is using gvfs for this, which is drawing in a lot of the Gnome stack and spawns many background processes, so we might want to replace it with something much leaner anyway

What do you think @moochris?

[ghost]

I would agree that option 3 would be better for the reasons you give, particularly that it is 'the FreeBSD way'.

I'm new to FreeBSD via helloSystem, so I'm a bit unsure about alternatives to gvfs on FreeBSD - would be good to look into this and see what is available. Adding some code to browse for the ssh service with libdnssd (we're avoiding avahi and using mdnsresponder, right?) is easy enough, but I'm not sure about accessing the discovered ssh:// share.

[probonopd]

Adding some code to browse for the ssh service with libdnssd (we're avoiding avahi and using mdnsresponder, right?) is easy enough

Yes, it would be ideal if Filer would not need Avahi; but we need to ensure that Filer does not prevent Avahi from working (or vice versa) because some other software on the system may still require it.

I'm not sure about accessing the discovered ssh:// share.

That part should hopefully be really easy using https://www.freshports.org/sysutils/fusefs-sshfs. (Should probably also do a similar thing for smb://.)

[DamjanJovanovic]

I am here to make an argument in favor of bsdisks and gvfs.

Over the last month I've helped to test, debug and fix bsdisks extensively. I have plugged and unplugged my USB drive 461 times (records available on demand), and explored every little issue until I got it working perfectly. GEOM classes with NULL and "wither" providers, which often occur, due to I/O errors when the USB drive wasn't plugged in properly, no longer cause it to crash. When devd drops it, it reconnects instead of using 100% CPU. It correctly reports EBUSY to gvfs for use in its "apps have files open" workflow, drive names are formatted correctly, and so on. I've been using it and testing it a lot since, and the remaining bugs I found are in the kernel, gvfs, Thunar, lsof, etc. - not in bsdisks. Now I am not saying go and try it now - version 0.24 in Ports doesn't have any of those fixes - but try the next release or the latest code in its source repository.

As for gvfs, it provides a lot of useful functionality, it's required by many file managers (Mint Linux's Nemo, Nautilus, XFCE's Thunar, probably more). It doesn't really "draw in a lot of the GNOME stack", for example glib is used by Qt too. It works well. Unlike the various automounting mini-projects, gvfs + bsdisks can (still developing this) send SCSI commands to power down the drive, spinning down the disk and turning off any device light, before removal. It notifies the file manager to show progress dialogs, such as "Writing data..." and "Can now be safely removed". Also if you have files open when unmounting the device, it helps the file manager to show which apps have them open:

and in addition to cancelling that unmount or forcing it to unmount anyway, you can also close the open files, which will automatically resume unmounting, and tell you when the drive can be safely removed (patch pending for that last bit).

gvfs does far more than the simple automount tools, not to mention provide countless other backends and protocols like MTP for cameras and phones. The reason it "spawns background processes" is for reliability, gnome-vfs didn't and crashed apps a lot. Yes it's LGPL, yes it's somewhat GNOME-y, yes it's not exactly "the FreeBSD way", but bsdisks allows us to subvert gvfs, and prevents gvfs from dragging in udisks2, udev and systemd, which frees FreeBSD from Linux's architecture :smiley:.

[probonopd]

Thanks @DamjanJovanovic. It seems that mainly Gtk based projects are using gvfs. We want to get away from that stack. Stretch goal: Get rid of glib. (Unfortunately Qt still has a dependency on it.)

[DamjanJovanovic]

If you are trying to make a general-purpose desktop, there is no getting away from "that stack", as users will install third-party apps that require most of that stack. Third-party apps always outnumber even the most prolific desktop vendor's own apps - consider how hundreds of Microsoft's own apps are dwarfed by the number of third-party Windows apps, and many useful GNOME-y apps exist already, including essential ones like LibreOffice and Firefox. And yes, LibreOffice and Firefox use gio, which will use gvfs when present.

KDE made a getaway. Kind of. KDE's solid does the drive management, and kio does the URL protocol handling, whereas gvfs does both. Drive management, such as mounting removable drives, converges on UDisks2 in both cases.

Solid looks pretty good, supports a password entry workflow for encrypted drives, etc. But KIO? GVFS exports all of its files locally over FUSE, allowing even KDE apps to immediately access a remote file through the local FUSE file, whereas it's been said KDE is in decline because of KIO. KIO downloaded remote files in full, before launching non-KDE applications with that local copy, which must have gone really well when the file was big, or needed for editing instead of viewing. A KIO to GVFS bridge was in development some years ago but died out. They eventually (KIO 5.66+) wrote kio-fuse to export KIO filesystems over FUSE like GVFS does. Even KDE fans seem to prefer GVFS.

In closing, there are 2 problems GVFS solves, drive management and URL protocol handling. For drive management you can use KDE's Solid instead, which is used by KDE's Dolphin, whereas Thunar, PCmanFM, Nemo, GNOME Files all expect GVFS, and without it they'll chug along with gio's minimal internal functionality. GVFS and Solid should be able to co-exist. As for protocol handlers, apps can get launched with FUSE links using either GVFS or recent KIO, but to open URLs internally within an application, eg. to browse to an ssh:// URL in Nemo, you need GVFS. Protocol handlers also matter for file open and file save dialogs, eg. without GVFS, GTK's dialogs can only see local files, or maybe access the pre-existing FUSE filesystems, and presumably KDE's dialogs without Solid have the same problem.

IIRC Lumina already took the fundamentalist, no DBus, automounter approach. They didn't get far.

[probonopd]

Well, why not just use e.g., sshfs to mount a network share? No need for daemons running in the background all the time and abstraction layer over abstraction layer.

Even KDE fans seem to prefer GVFS.

That is incrasingly the trouble with KDE - it's just another layer of abstraction and sugar coating on top of the Gnome stack. Consequently, we try to stay away from Kf5 wherenever possible as well...

[DamjanJovanovic]

Well, why not just use e.g., sshfs to mount a network share? No need for daemons running in the background all the time and abstraction layer over abstraction layer.

Users and apps like URLs to open automatically within the UI.

GVFS protocol handlers (archive, ssh, smb, nfs, cdda etc.) are launched on demand, and only the monitors like udisks2, mtp and gphoto2 run all the time. I am not sure about Solid/KIO.

Now that you mention it though, I have to admit, a total RSS of almost 93 MiB when not in use, is somewhat concerning:

	PID	VSZ	TSIZ	DSIZ	SSIZ	RSS	COMMAND
	3866	36532	16	8	128	11456	/usr/local/libexec/gvfsd-network
	4786	34116	16	8	128	11384	/usr/local/libexec/gvfsd-dnssd
	10454	30780	20	4	128	9140	/usr/local/libexec/gvfsd
	22456	42428	96	8	128	14756	/usr/local/libexec/gvfs-udisks2-volume-monitor
	26251	27208	48	12	128	7660	/usr/local/libexec/gvfs-mtp-volume-monitor
	31719	28396	48	12	128	8344	/usr/local/libexec/gvfs-gphoto2-volume-monitor
	34982	24580	48	8	128	7736	/usr/local/libexec/gvfsd-metadata
	44670	34364	28	4	128	10940	/usr/local/libexec/gvfsd-trash
	66301	34120	20	4	128	11144	/usr/local/libexec/gvfsd-computer
TOTAL		292524	340	68	1152	92560

Even KDE fans seem to prefer GVFS.

That is incrasingly the trouble with KDE - it's just another layer of abstraction and sugar coating on top of the Gnome stack. Consequently, we try to stay away from Kf5 wherenever possible as well...

Not in this case. As per the earlier picture, they both came up with the same kind of architecture, and KIO predates GVFS. Though I wonder if KIO runs in the background and eats RAM like GVFS monitors.

[DamjanJovanovic]

Well, why not just use e.g., sshfs to mount a network share? No need for daemons running in the background all the time and abstraction layer over abstraction layer.

Also if we look at history, Windows had "Network Neighborhood" and shell namespaces since at least Windows 95, and Mac's AppleTalk probably earlier.

Windows users never really mounted drives themselves, Windows automatically mounts them as soon as a new filesystem is detected (except for floppy drives, where media change cannot be detected).

That's where *nix desktops have also gone - eg. XFCE's thunar-volman lets you configure removable drives to automatically mount and open up a new file manager window with their contents, as well as automatically run autorun.inf on optical discs. When the user clicks "Safely remove" or the drive is unplugged without unmounting, the file manager windows automatically close or change their cwd to $HOME, so they don't cause the unmount to fail with "Device busy" or give I/O errors on files that are no longer there. That level of cohesive integration requires support from every component involved, requires communication and coordination between several processes (DBus RPCs and events), requires device change events to be transmitted from the bottom up (kernel->daemons->DBus->apps), and can't really be implemented if you use a DBus-less automounter with no awareness of the desktop.

[probonopd]

For local disks, we are also mounting them automatically for the user.

For network disks, the Mac had the Chooser:

Users always had to select a network device and "mount" (although the term was not used) it manually.

We have the Zeroconf utility:

Integrating parts of its functionality into the Filer and, if possible, into Qt File Open/Save dialogs would be neat. But still, no ever-running background processes needed!

[probonopd]

somewhat concerning

Speaking of which...

https://github.com/helloSystem/Filer/issues/45