Hi, some removable media cannot be unmounted from Thunar. Option "Unmount" is missing, there is only option "Eject". Unfortunatelly, "Eject" does not unmount it, but it raise a pop-up window with "Unknown error". Output of lshal from affected devices are here: http://www.kmarty.bluetone.cz/tst/thunar/must_be_unmounted_because_eject_ends_with_error/prestigio_pocket_drive_over_usb.lshal http://www.kmarty.bluetone.cz/tst/thunar/must_be_unmounted_because_eject_ends_with_error/sdcard_in_non-usb_reader.lshal http://www.kmarty.bluetone.cz/tst/thunar/must_be_unmounted_because_eject_ends_with_error/wd_mybook_over_firewire.lshal http://www.kmarty.bluetone.cz/tst/thunar/must_be_unmounted_because_eject_ends_with_error/wd_mybook_over_usb.lshal
Created attachment 1844 20GB Prestigio Pocket drive over USB
Created attachment 1845 SD card in non-USB (integrated) card reader
Created attachment 1846 Western Digital MyBook hard drive over Firewire
Created attachment 1847 Western Digital MyBook hard drive over USB
Added output of lshal as attachments.
I think it may be related to the is_ejectable function in thunar-vfs-volume-hal.c: static gboolean thunar_vfs_volume_hal_is_ejectable (ThunarVfsVolume *volume) { /* check if HAL drive requires eject */ if (THUNAR_VFS_VOLUME_HAL (volume)->requires_eject) return TRUE; /* otherwise we can only eject removable media, that are present (surprise, surprise) */ return (thunar_vfs_volume_is_present (volume) && thunar_vfs_volume_is_removable (volume)); } With volume_hal->requires_eject = libhal_drive_requires_eject (hd); If requires_eject is present and is true, the volume is marked as ejectable. If it's present and false, or not present, it depends. But in the case the device is present and removable, it's assumed to be ejectable, which seems wrong in some cases. Maybe in the general case it's ok, but when requires_eject is present and false, I guess thunar should consider it as ejectable. Cheers, -- Yves-Alexis
(In reply to comment #6) > If requires_eject is present and is true, the volume is marked as ejectable. > > If it's present and false, or not present, it depends. But in the case the > device is present and removable, it's assumed to be ejectable, which seems > wrong in some cases. > > Maybe in the general case it's ok, but when requires_eject is present and > false, I guess thunar should consider it as ejectable. I just checked with an usb token I have, and: storage.requires_eject = false (bool) storage.serial = 'Kingston_DataTraveler_2.0_5B7B0DB10058-0:0' (string) which means if we use something like: return (THUNAR_VFS_VOLUME_HAL (volume)->requires_eject); it won't be marked as ejectable, while it should be ejected. Maybe in that case it's a bug in hal, which doesn't correctly set the requires_eject properties. But anyway, “requires_eject” means that, if present, it should be ejected, but if not it doesn't say anything, so maybe letting the user choose would be a good idea. What do you think? Cheers, -- Yves-Alexis
No, I think this is a bug in HAL, or at least some weird issue with the reporter's hardware. Not sure it can be worked around in thunar-vfs.
(In reply to comment #8) > No, I think this is a bug in HAL, or at least some weird issue with the > reporter's hardware. Not sure it can be worked around in thunar-vfs. I'm not sure. In the reporter's case we have requires_eject=false. I agree this is not equivalent to never_eject, but I would find it more consistent do only propose eject when requires_eject=true, and not in other cases.
Hmhm, I guess this may be related/duplicate to/of bug #3978
(In reply to comment #7) > (In reply to comment #6) > > If requires_eject is present and is true, the volume is marked as ejectable. > > > > If it's present and false, or not present, it depends. But in the case the > > device is present and removable, it's assumed to be ejectable, which seems > > wrong in some cases. > > > > Maybe in the general case it's ok, but when requires_eject is present and > > false, I guess thunar should consider it as ejectable. > > I just checked with an usb token I have, and: > > storage.requires_eject = false (bool) > storage.serial = 'Kingston_DataTraveler_2.0_5B7B0DB10058-0:0' (string) > > which means if we use something like: > > return (THUNAR_VFS_VOLUME_HAL (volume)->requires_eject); > > it won't be marked as ejectable, while it should be ejected. Maybe in that case > it's a bug in hal, which doesn't correctly set the requires_eject properties. Why would your Kingston device need to be ejected? If it's just an ordinary USB stick sort of thing it should just be unmounted, not ejected. BTW, without knowing about this bug, I committed the exact same thing you suggested before to Thunar today (bug #3978): thunar_vfs_volume_hal_is_ejectable() now returns TRUE if and only if requires_eject is TRUE.
(In reply to comment #11) > Why would your Kingston device need to be ejected? If it's just an ordinary USB > stick sort of thing it should just be unmounted, not ejected. Hmhm, right, not sure. I don't really know how the powering stuff works with usb flash tokens. When “ejecting” a partition currently, all the other partitions on my usb tokens are umounted and disappear (which can be convenient when you don't want to umount all of them manually, but can't be painfull when you just want one to be unmounted). What would be nice, I guess, would be a way to separate an hardware device (even a pseudo device, like a crypto layer) and the partition on it. Somethine like a treeview: + USB Token 1 USB Token 1, partition 1 + USB Token 1, partition 2, crypto layer USB Token 1, partition 2, crypto layer, partition 1 USB Token 1, partition 3 + USB Token 2 USB Token 2, partition 1 In that case the lines prefixed by + would be the “nodes” of a treeview and could be “ejected” using a right click (if they are marked ejectable, eject them, if not, umount all partitions on it, something like that). The partition themselves would only be umountable, I guess. (or maybe ejectable if partitions can have an is_ejectable=true HAL property) Not sure if I'm really clear with that, nor if it's doable and easy. That's something for later Thunar I guess. > > BTW, without knowing about this bug, I committed the exact same thing you > suggested before to Thunar today (bug #3978): > thunar_vfs_volume_hal_is_ejectable() now returns TRUE if and only if > requires_eject is TRUE. Yeah, thanks. I wont be able to test that now (except if the patch applies to beta 2) but will report back at rc1. Cheers, -- Yves-Alexis
(In reply to comment #12) > (In reply to comment #11) > > Why would your Kingston device need to be ejected? If it's just an ordinary USB > > stick sort of thing it should just be unmounted, not ejected. > > Hmhm, right, not sure. I don't really know how the powering stuff works with > usb flash tokens. When “ejecting” a partition currently, all the other > partitions on my usb tokens are umounted and disappear (which can be convenient > when you don't want to umount all of them manually, but can't be painfull when > you just want one to be unmounted). Yeah, that's clearly not the desired behaviour. It should show unmount for all devices and you should be able to mount/unmount them independently. > What would be nice, I guess, would be a way to separate an hardware device > (even a pseudo device, like a crypto layer) and the partition on it. Somethine > like a treeview: > > + USB Token 1 > USB Token 1, partition 1 > + USB Token 1, partition 2, crypto layer > USB Token 1, partition 2, crypto layer, partition 1 > USB Token 1, partition 3 > + USB Token 2 > USB Token 2, partition 1 > > In that case the lines prefixed by + would be the “nodes” of a treeview and > could be “ejected” using a right click (if they are marked ejectable, eject > them, if not, umount all partitions on it, something like that). The partition > themselves would only be umountable, I guess. (or maybe ejectable if partitions > can have an is_ejectable=true HAL property) > > Not sure if I'm really clear with that, nor if it's doable and easy. That's > something for later Thunar I guess. Yes. We'll see how volume stuff works in GIO/GVfs. But what you suggested sounds confusing from the user's point of view. We need something straight forward and easy to use, so in this case I'd probably stick to the independent unmounting of partitions rather than going for a weird hybrid solution ;) > > BTW, without knowing about this bug, I committed the exact same thing you > > suggested before to Thunar today (bug #3978): > > thunar_vfs_volume_hal_is_ejectable() now returns TRUE if and only if > > requires_eject is TRUE. > > Yeah, thanks. I wont be able to test that now (except if the patch applies to > beta 2) but will report back at rc1. It should apply against beta 2, I think.
(In reply to comment #13) > Yeah, that's clearly not the desired behaviour. It should show unmount for all > devices and you should be able to mount/unmount them independently. Yeah but an “unmount all” can be really useful :) > […] > Yes. We'll see how volume stuff works in GIO/GVfs. But what you suggested > sounds confusing from the user's point of view. We need something straight > forward and easy to use, so in this case I'd probably stick to the independent > unmounting of partitions rather than going for a weird hybrid solution ;) Yeah but that's more or less what is done on OSX finder iirc (I'll check that tonight) > > > > BTW, without knowing about this bug, I committed the exact same thing you > > > suggested before to Thunar today (bug #3978): > > > thunar_vfs_volume_hal_is_ejectable() now returns TRUE if and only if > > > requires_eject is TRUE. > > > > Yeah, thanks. I wont be able to test that now (except if the patch applies to > > beta 2) but will report back at rc1. > > It should apply against beta 2, I think. Nice, i'll try. Thanks.
*** This bug has been marked as a duplicate of bug 3978 ***