Red Hat Bugzilla – Bug 130866
'gthumb --import-photos' fails with mounted usb-storage device
Last modified: 2013-03-13 00:46:31 EDT
Description of problem:
gnome-volume-manager will invoke 'gthumb --import-photos' when you
plug in a camera and agree to import photos into your photo album.
However, this fails altogether for cameras that implement USB mass
storage, since they have already been mounted (the check for 'dcim/'
is what triggers the import).
What is the right solution here? Should gthumb handle this (how can
it know where to copy files from)? Or gphoto2 (same question)? Or
should gnome-volume-manager be smarter?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Plug in a USB mass storage camera
CCing dave on this. I'm guessing that it is best to for g-v-m not to
mount the drive if import is selected. Dsrt on #gnome-devel is
working on a dbus gphoto2 daemon which would allow multipule
applications to access a device at once but I am not sure if we can
get this in fc3 or not. It would also involve porting gthumb.
Another option is to turn off auto importing alltogether for this
forgot to cc david
Uhm, maybe I'm missing something here.
1. If your camera is USB Mass Storage based g-v-m will think it's a
disk and mount it. The presence of a DCIM tree will trigger the "You
have new pictures" dialog that eventually takes you to 'gthumb
--import-photos'. This will also be true for card readers with media
that has a DCIM tree. I take this is what this bug is about.
2. If your camera is not based on USB Mass Storage and it got the hal
capability 'camera' g-v-m also launch 'gthumb --import-photos' (Btw,
I've written a hal callout that looks at /etc/hotplug/usb.usermap to
The bug is really upstream in g-v-m; it only gives *one* program for
two *different* uses.
Suggestion to write patch to g-v-m that enables the program to contain
the HAL UDI (I need to write a few other small patches so I can do
this and I'm confident it will be merged upstream) and write a wrapper
for gthumb that does either 'gthumb /media/usbdisk1' or 'gthumb
--import-photos' depending. Then the g-v-m capplet would contain
'launch-gthumb %h' and all would be well.
Long term solution is more complicated, but this will at least make it
work well for all digital cameras and card readers that are USB
Storage + all digital cameras supported by gphoto2.
Ok, I see. What I was missing was the discussion about unmounting and
using gphoto2; I see now. This is not really feasible; we want to
support card readers as well and only very few cameras support both
USB Mass Storage and e.g. PTP as used by gphoto2.
I got my patch merged upstream in g-v-m after nagging the maintainer;
he even released 0.9.10. I've also built the callouts into hal so we
properly detect gphoto2-based cameras.
So as I see it only the following things need to be done
1. Add X-Red-Hat-Base to Categories in .desktop file (magicdev was in
2. Install the gvm-gthumb wrapper (there is one at
3. Tweak defaults to point to gvm-gthumb wrapper
(might come up with a better name than gvm-gthumb)
Re: Comment #3
Can you explain scenario 1 a little more.
I get the dialog with cancel/import as the options. I select import
and gthumb is just completely confused because it seems to be
expecting a camera and not a mounted filesystem.
Gthumb's import Photos dialog shows up... with a no camera detected
icon.. a destination as /home/username and blank film and categorie
fields. I try to hit import and I get a 'could not import photos: no
camera detected' dialog. So it appears to me like hal and g-v-m are
doing the clever thing and starting gthumb. but gthumb seems to be
completely confused by the idea of mounted media with a dcim directory
and looks to be expecting a camnera it can probe with libgphoto.
/media/usbdrive/dcim exists and there are photos on the disk.
Do i need to open up a bug against gphoto about this? What is the
exaxct command that gets run to call gthumb in this case?
does --import-photos take a location argument? How does gthumb know to
look at /media/usbdrive/dcim ?
Hi, this is fixed in Rawhide; you'll need gnome-volume-manager
0.9.10-2 and hal-0.2.97.cvs20040901-1.
If you have changed the defatuls in the "Removable Storage"
preferences capplet, you need to set 'gthumb-import %h' as the command
to invoke when importing digital photo albums.
fixed gthumb-import %h opens in the directory.
One thing.. do you want it to open into the dcim subdirectory by
default? instead of the top directory of the media?
David, does all photo media have the dcim subdirectory? If so then
yes. Actually I can just put a test in the script to see if it exists
and use that directory if it does. Any objections?
Yeah, although dcim may be in uppercase as well IIRC. Putting it in
the script will help but the user will still have to select the subdir
with the pictures and this is camera specific. My camera uses canon122
and so forth.
All detailed in DCF, see http://www.exif.org/dcf.PDF (btw this doc
raises some interestering requirements for the Perfect(tm) photo mgmt
app; e.g. Reader 2 playback; ask to print tagged pictures etc.)
Also note that there may be several subdirectories below DCIM if the
media has been used with different devices.
my point is... if the request for importing the pictures from media
is done just by checking for a dcim or DCIM directory to even get the
dialog, it makes some sense to open up to the dcim directory becuase
im not all that sure that Al "the average user" Consumer is going to
know that DCIM is the directory to browse down into. If the existance
of the dcim directory is indeed what triggers the prompt open up to
My camera, and i would imagine other cameras. let me name the
subdirectories under DCIM to some extent and I can even choose which
directory to use from the camera menu... the menu item right above "do
my taxes" and just below "save the whales." Regardless though, seeing
a set of subdirectories named NikonXXX or CanonXXX is going to be much
more intutitively understood as photo directories than DCIM.
-jef"my 3 cents, you own me 1 penny in change"spaleta
Hehe, I guess I should have posted earlier but this is fixed and
holding for after FC3 test2 is out. The bug is not critical enough to
hold up test2 in QA. The wrapper script just checks to see if the
dcim or DCIM directory exists and uses that as the base directory.
Just as refrence this should have been opened up as a new bug, not
appended to an already closed bug.
Closed for real this time ;-)