GNOME Bugzilla – Bug 579634
2 autorun and an error dialog when I plug in my camera
Last modified: 2018-09-21 16:43:14 UTC
When I plug in my camera, I get two autorun dialogs plus and error dialog. I can understand the two autorun dialogs, since there are two actual stores on the camera (see the attached gphoto2 --summary output), but the error dialog is kinda bad. It says: Unable to mount Kodak Co. Digital Camera Error initializing camera: -60: Could not lock the device So I assume what is happening is that gvfs is mounting the camera when it sees the first storage, and then when it tries to handle the second one, the camera is already mounted. Is there a way for the gphoto backend to notice that the camera is already mounted, and return an already-mounted error in this case ?
Created attachment 132970 [details] gphoto2 --summary output
[mclasen@planemask Desktop]$ gvfs-mount -l Drive(0): HL-DT-ST DVDRAM GSA-U10N Type: GProxyDrive (GProxyVolumeMonitorGdu) Volume(0): Kodak Co. Digital Camera Type: GProxyVolume (GProxyVolumeMonitorGPhoto2) Volume(1): Kodak Co. Digital Camera Type: GProxyVolume (GProxyVolumeMonitorGPhoto2) Volume(2): Kodak Co. Digital Camera Type: GProxyVolume (GProxyVolumeMonitorGPhoto2) Volume(3): Kodak Co. Digital Camera Type: GProxyVolume (GProxyVolumeMonitorGPhoto2)
Created attachment 132974 [details] gvfs-mount -li output
activation_root=gphoto2://[usb:005,002]/store_00020001 activation_root=gphoto2://[usb:005,004]/store_00020001 activation_root=gphoto2://[usb:005,008]/store_00020001 activation_root=gphoto2://[usb:005,009]/store_00020001 This suggests that the gphoto2 volume monitor isn't cleaning things up correctly. Also looks fishy these are not attached to a drive (I think they should be). Please try this - remove your camera - run /usr/libexec/gvfs-gphoto2-volume-monitor in a shell (this will replace the current gphoto2 volume monitor) - start capturing 'gvfs-mount -oi' output in another shell - plug in your camera and then attach the captured 'gvfs-mount -oi' output as well as the output of 'gvfs-mount -li'. Also let me know how many automount dialogs this gives you.
fun, experiments. I get the same number of automount and error dialogs as before.
Created attachment 132975 [details] gvfs-mount -oi output
Created attachment 132976 [details] gvfs-mount -li output
The two autorun dialogs are expected, I think. Just curious, does both mounts have a DCIM folder in the root? I guess you get the error dialog because Nautilus is trying to automount the two volumes at the same time... and since they share a common mount, two Mount() calls are racing to win and only one of them wins. FWIW, I get the same behavior with another daemon backend $ for i in 1 2 ; do (gvfs-mount sftp://quad.local &) ; done $ Error mounting location: DBus error org.freedesktop.DBus.Error.InvalidArgs: Mountpoint Already registered $ The question is how to best resolve this. I think the losing Mount() call should error out with G_IO_ERROR_ALREADY_MOUNTED and then we should ensure that Nautilus shuts up if this is the case (it would still put up autorun dialogs). This should be solved at gvfsd level, e.g. two simultaneous calls g_file_mount_enclosed_volume ("gphoto2://[usb:005,011]/", ...); that results in bringing up the same mount, should be serialized instead of trying to bring up two mount daemons at the same time. So the error dialog is, I think, a bug in the core GVfs daemon code. Alex? So, I think we actually have three separate bugs here - we should ignore very small storage heads on gphoto2 devices (this bug) - gvfsd should serialize Mount() calls (please clone this bug) - Nautilus should shut up on G_IO_ERROR_ALREADY_MOUNTED if it doesn't already (please file)
Of course I could be wrong about this and that gvfsd already works correctly. Please try to make each instance of gvfsd-gphoto2 append debug output (including it's pid) to a well-known text file (e.g. /tmp/gvfsd-gphoto2-debug-out.txt) and repeat the experiment. That way we can see if multiple instances of gvfsd-gphoto2 are really brought up for multiple simultaneous mount calls.
only serialization right now is when registering. Should be fixed. And we should ignore the ALREADY_MOUNTED error, true.
> The two autorun dialogs are expected, I think. Just curious, does both mounts > have a DCIM folder in the root? No, one has DCIM, the other one is empty. Which brings up the question why they are both tagged as x-content/image-dcf
(In reply to comment #11) > > The two autorun dialogs are expected, I think. Just curious, does both mounts > > have a DCIM folder in the root? > > No, one has DCIM, the other one is empty. Which brings up the question why they > are both tagged as x-content/image-dcf Because: 1) the gphoto backend hard codes that it has x-content/image-dcf 2) g_mount_guess_content_type() doesn't check for files using g_content_type_guess_for_tree() Bug 530651
(In reply to comment #11) > > The two autorun dialogs are expected, I think. Just curious, does both mounts > > have a DCIM folder in the root? > > No, one has DCIM, the other one is empty. Which brings up the question why they > are both tagged as x-content/image-dcf IIRC because we assume that all cameras contains pictures and sniffing gphoto2 devices (and for that matter other non-native backends) with a hammer like that of g_content_type_guess_for_tree() seems a bit... excessive? Also, the way things work is that this happens from the backend code itself, g_vfs_backend_set_x_content_types() mainly because it is a per-backend decision whether sniffing is supported (no, you really don't want to sniff a remote share on the other side of the planet) and g_content_type_guess_for_tree() won't work there since we don't have a GFile for the root... For gphoto2 we could be smarter about this, in fact there's a TODO item /* TODO: should we sniff the files instead? */ about it. But that's not really the way things work right now. Maybe we could manually check for the DCIM folder though.
Checking for DCIM sounds like a great idea to me.
Aren't we using gphoto to access some non-camera things too? Like some ipod or something like that?
(In reply to comment #15) > Aren't we using gphoto to access some non-camera things too? Like some ipod or > something like that? Yep, and the code "handles" that too - see find_udi_for_device() in daemon/gvfsbackendgphoto2.c. I don't think there's an easy answer expect for fixing bug 530651...
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/90.