Red Hat Bugzilla – Bug 174948
False volume.is_mounted and blank volume.mount_point property when memory card is mounted
Last modified: 2013-03-05 22:44:37 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7 Description of problem: Several components (e.g. gnome-volume-manager) appear to read the volume.mount_point property to figure out what to do with a device. By using lshal, one can see that this is blank (property exists, value is zero-length string) even though the volume is properly mounted and accessbile at the "desired mount point", evidently by fstab-sync. For some reason, hal is not acknowledging that the device is mounted. This occurs on several i686-type systems I am using, although I should point out I am using kernel 2.6.14-1.1637_FC4 on all of them instead of the (old) stock FC4 kernel. It also happens with multiple cards, from several different cameras. More specifically I am trying to get photos off of a USB flash card/reader using the gnome-volume-manager and it doesn't recognize that the card contains pictures. From the manager source code it is clear that it decides that the card contains photos if the path at "volume.mount_point" for the udi sent to it contains a directory "dcim". Since the mount_point is blank, this obviously always fails, and it assumes there are no photos on the device. To be clear, from the xsession log, it is visible that gnome-volume-manager is interacting with signals from hotplug/hal and receives the correct udis for the card. It just never enters the proper code path for the reason just mentioned above. Version-Release number of selected component (if applicable): hal-0.5.2-2 How reproducible: Always Steps to Reproduce: 1. insert flash drive with photos on it 2. 3. Actual Results: drive appears in fstab, is mounted, appears as icon on desktop. Photo acquisition of gnome-volume-manager is never triggered. Expected Results: The photo extraction of gnome-volume-manager should be triggered. Additional info:
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
I can only assume that this bug still exists with FC4, as I have moved on, and this report didn't have a fix after all this time, or even an acknowledgement that anyone was working on it. I haven't run into the same problem under FC5, FC6. With FC4 EOL'd I assume you want _me_ as the reporter to mark the bug as resolved as WON'T FIX, as odd as that seems, since RH/Fedora is the entity making the decision to EOL.