Bug 984913 - gvfs-gphoto2 fails when copying files from the camera using caja or nautilus
gvfs-gphoto2 fails when copying files from the camera using caja or nautilus
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: glib2 (Show other bugs)
19
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Matthias Clasen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-16 07:07 EDT by markm
Modified: 2013-11-24 11:14 EST (History)
19 users (show)

See Also:
Fixed In Version: glib2-2.36.3-4.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-23 14:48:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
screenshot of error message (132.82 KB, image/png)
2013-07-22 09:45 EDT, Jeff Layton
no flags Details

  None (edit)
Description markm 2013-07-16 07:07:49 EDT
Description of problem:

When trying to copy files from the camera using any software relaying on gvfs-gphoto2, I get the following error: "Operation not supported by backend"

Version-Release number of selected component (if applicable):

gvfs-ghoto2-1.16.3-2.fc19.x86_64

How reproducible:

always (on two different machines, tested with Caja, Nautilus, Thunar)

Steps to Reproduce:
1. Install gvfs-gphoto2
2. Connect camera
3. Browse images
4. Attempt to copy images

Actual results:

A popup error message appears "Operation not supported by backend"

Expected results:

Files copied without error message

Additional info:

$ gphoto2 -P
downloads all files with no issues

also installing any software capable of importing images (darktable, shotwell) will import them without any issues too, though none of these apps are installed by default on MATE Desktop, separate bug was filled for it: https://bugzilla.redhat.com/show_bug.cgi?id=984908 ).
Comment 1 Jeff Layton 2013-07-22 09:45:40 EDT
Created attachment 776906 [details]
screenshot of error message

"Me too..."

Here's a screenshot showing the error. Marking with a priority of "high" due to wife grief factor ;).
Comment 2 Paul Finnigan 2013-07-26 09:57:43 EDT
Ditto.

Opening the files directly in various editing packages and there is no issue.
Comment 3 Cornelia Pfeffer 2013-07-30 06:11:50 EDT
I have the same problem now, but only with a Canon Power Shot SX 260 HS, while I don't have this problem with the old Nikon Coolpix 4100.
Comment 4 smanocch 2013-09-07 02:46:57 EDT
Same problem with canon 50d
Comment 5 Denis Auroux 2013-09-18 00:47:14 EDT
Same problem with iPhone 5. The gvfs mount works fine in a terminal, but copying the files in nautilus, which used to be the easiest way to download the photos on F17, now just gives "Operation not supported by backend" after upgrading to F19.

I am pretty sure the problem is with either gvfs or nautilus, not with specific cameras. In fact, I am also not completely sure but I think the iPhone uses gvfs-afc, not gvfs-gphoto2 -- so this may be a general problem that affects more than one backend. gvfs-gphoto2 is probably not the main culprit -- I'd look at the nautilus/gvfs interaction.
Comment 6 Denis Auroux 2013-09-18 00:58:32 EDT
Ah, in fact, here's a lower-level manifestation of the same problem, still on iPhone -- no nautilus or other file manager involved, it's clearly 100% a gvfs problem. Someone with a camera with a gvfs-gphoto2 mount could try to confirm whether the same issue happens with gvfs-gphoto2 as with gvfs-afc -- I suspect that's probably the case.

~ > gvfs-ls afc://e545[...]c3df/DCIM/100APPLE/
[...]
IMG_0462.JPG
IMG_0463.JPG
~ > gvfs-copy afc://e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG .
Error copying file afc://e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG: Operation not supported by backend
~ > ls /run/user/500/gvfs/afc:host=e545[...]c3df/DCIM/100APPLE/
[...]
IMG_0462.JPG
IMG_0463.JPG
~ > cp /run/user/500/gvfs/afc:host=e545[...]c3df/DCIM/100APPLE/IMG_0463.JPG .
[file copies successfully]
Comment 7 Ejner Fergo 2013-09-26 11:04:57 EDT
I have the same problem in Thunar filemanager.

Connecting a camera (eg. canon 50d) shows up immediately in Thunar device list, and browsing images on the camera is possible, even thumbnails are created. Trying to open an image in eg. Geeqie, by double-clicking it in the filemanager, does not work however, and neither does copy/paste from the gphoto2 location via the filemanager.

Nothing gets populated in /run/user/1001/gvfs/ or /run/media either.
Comment 8 Ondrej Holy 2013-10-11 10:13:47 EDT
Probably connected with:
https://bugzilla.gnome.org/show_bug.cgi?id=706254
Comment 9 Jan Pazdziora 2013-10-19 08:37:13 EDT
(In reply to Ondrej Holy from comment #8)
> Probably connected with:
> https://bugzilla.gnome.org/show_bug.cgi?id=706254

That bug now has a varified patch.

Can we get Fedora 19 package(s) fixed and respun?
Comment 10 Panu Matilainen 2013-10-29 02:58:15 EDT
FWIW I can verify https://git.gnome.org/browse/glib/commit/?id=be2656f13952dd22d348ff5e3f43240700cdef5a fixing the issue here. Wife happy now, I'm going to be happy once this has been pushed as an update to Fedora so I dont need to maintain a locally built version of glib2.

And yes the patch in question is on glib2, not gvfs, switching to correct component.
Comment 11 Wade Hampton 2013-11-02 14:24:26 EDT
Detected same issue with Fedora 19 x86_64 after update from F18.
Same computer/camera worked fine on F18 prior to the update 
last weekend.  Camera is Canon 50D.

I can manually copy the files from the command line.

I belive bug 986543 is a duplicate of this bug.
Comment 12 David Green 2013-11-05 10:30:06 EST
I have the same problem on F19 x86_X64 with a Kodak Easyshare M590 camera and my iPhone.  Workaround is either to use a program such as GIMP to open off the device and save to my HDD or to copy files via command line
Comment 13 Richard W.M. Jones 2013-11-17 04:50:41 EST
Fails to me too, Fedora 19.
Comment 14 Richard W.M. Jones 2013-11-17 05:11:24 EST
I've added that patch to the Fedora 19 glib2 package.
Comment 15 Fedora Update System 2013-11-17 05:18:04 EST
glib2-2.36.3-4.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/glib2-2.36.3-4.fc19
Comment 16 Fedora Update System 2013-11-17 21:54:59 EST
Package glib2-2.36.3-4.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glib2-2.36.3-4.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21576/glib2-2.36.3-4.fc19
then log in and leave karma (feedback).
Comment 17 Richard W.M. Jones 2013-11-21 05:11:23 EST
As I understand it, we need one more person to test the
update (see comment 16) and up-vote it, and then it can
be pushed to Fedora 19 stable.
Comment 18 Panu Matilainen 2013-11-21 06:30:41 EST
Meh, I intended to do test it a while ago but just forgot... anyway, done + "voted" now. Oh and thanks Richard for bothering to make the update!
Comment 19 Fedora Update System 2013-11-23 14:48:42 EST
glib2-2.36.3-4.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 20 David Green 2013-11-24 11:14:45 EST
I confirmed the bug is fixed with the updated glib2 package in F19.  For the sake of completeness, I reproduced the bug in the last F20 Beta release, but it is fixed in F20 TC1.

Note You need to log in before you can comment on or make changes to this bug.