Try to stop or eject drive before ejecting volume from side-pane

[tsujan]

Lack of drive stopping/ejection caused USB sticks to remain powered after they were ejected by the app.

Closes #1048

NOTE 1: As far as I know, only USB sticks and optical media support ejection, in different senses. An external hard drive can only be unmounted, partition by partition.

NOTE 2: Please don't merge before 2.2.0 is released.

[isf63]

Will optical drives remain visible in computer:/// with no medium? The "Eject" button there has the ability to open the tray, regardless of being mounted.

[tsujan]

Yes, optical drives are different. But I'd appreciate it if you could test with optical drives; I have none here.

[tsujan]

Oh, if you test it, don't eject from inside computer:///; use the side-pane for ejection.

The behavior of computer:/// is like before because, apparently, GLib doesn't provide a way of finding the volume from a GFile, let alone the drive. I even wanted to remove the "Eject" menu item from computer:/// but thought it's useful for media devices. This seems to me like a drawback in GIO.

[isf63]

Testing, my USB thumbdrive doesn't have a "power on" light so it's identical as before. The "root" (/dev/sdd - not a partition) item along with its name still shows up in computer:/// after unmounting the partition(s). /dev/sr0 eject from computer:/// doesn't disappear the item.

There's a possibility I'm not on your branch though. Transitioning to Ubuntu and have not yet re-learned everything.

[tsujan]

I was lucky to be able to borrow 4 USB sticks, each of which showed a different behavior with this patch. With some, the item under Computer disappeared on ejecting from the side-pane, with others it didn't; and there was one USB stick that auto-connected after successful ejections. But the same thing always happened in Thunar.

Anyhow, this is the new behavior on ejecting from the side-pane, put in English:

1. The app first tries to stop the drive (like Thunar and Nautilus);
2. If not successful, it tries to eject the drive (like Thunar);
3. If not successful, it uses its usual method, which is successful under all normal circumstances.

The difference is that, if step 1 or 2 succeeds, the stick will also be powered off. That didn't happen before, when only step 3 was used. So, IMO, this change is a minor improvement.

When or why 1 or 2 succeeds, I don't know, and I doubt that GLib devs know either. Someone showed me the different behaviors of his USB stick on "safe removal" (= drive stopping/ejection) under Windows7 and Windows11. It's like tossing dice…