GNOME Bugzilla – Bug 673109
non usb storage devices need special care when ejecting
Last modified: 2020-03-17 09:25:06 UTC
Hi! I'm still playing with my SD card having all my Music from my rockbox device, and using the SD card reader from my X series thinkpad, with the mmc kernel layer (not the usb layer). I found that ejecting the device from banshee only does an umount of the mounted filesystem, but doesn't remove the device from the left pane. This is caused by mount.Volume being null in HandleMonitorMountRemoved(). So a possible workaround could be to add a dictionary to keep a trace of the association mount.Handle -> volume, just like this is done for the association mount.volume.Handle -> device. The same problem occurs when just *umounting* the filesystem from the filemanager. For USB devices, there's an option in the filemanager that says "safely remove the device" that does both actions : umounting and removing the usb device. For devices using the mmc layer, the only way to remove the device too is to remove the sdhci_pci kernel module. Proposed patch follows.
Created attachment 210897 [details] [review] Preserve the Volume object when an unattended umount occurs
Hey, I tried out the attached patch with my similarly afflicted Nokia, though connected by usb the unmount operation doesn't cause an eject of the device like it does with regular usb flash drives. I'm guessing this is a similar behaviour as Fabrice observes: i.e. when selecting eject for the mmc layer device the device nodes remain in /dev and the Source persists until device removal/kernel module removal. Anyway, the patch works to allow removal of the associated Source from banshee through just the HandleMountRemoved handler. I did a bit more testing however, and even for a usb drive which does eject during unmount we only remove it after the eject. The HandleMountRemoved actually hits the if (mount.Volume == null) return; statement every time-so the Source is actually removed in HandleVolumeRemoved. I did a bit more digging through the Manager, HardwareManager, DapService and a few others-it looks like all we actually need to remove the source is the string uuid of the device. I understand the problem with this, e.g. in the history apple devices were patched to return some other ID as they don't give a uuid and were displaying the same problem. But we have keyed the source dictionary to the uuid, so i'm assuming it's the most reliable property we have... Basically, i'm not sure if we should do all the p/invoke gymnastics associated with handling both signals. Is there anything we can do with a device after it's been unmounted? Maybe we could remove the source every time in HandleMountRemoved by using a: Dictionary<IntPtr, String> mount_uuid_map; To make that easier we could also revise the result-as we try to create a fully fledged device (with UdevMetaData, etc...) in the Manager's Handle{Volume,Mount}Removed just to pass it to the HardwareManager who only passes the uuid on. Then, we modify VolumeRemoved to just take the string and pass that on to eventually be unmapped and removed. Does that make sense? I get the primitive obsession, maybe it's the lesser evil in comparison with holding onto native objects... (I'm assuming that's what GLib.Volume and GUdev.Device's are, right?)
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.