[Regression] Can't copy files from digital camera (Operation not supported by backend)

[Jan Rathmann]

[ Description ]

Copying from some devices is broken over gvfs

[ Test case ]

- browse a directory with a .tar.gz, using nautilus
- right click on the file, select "open with archive mounter"

-> that makes the archive being listed as a mount in the sidebar/unity launcher

- browse that mount, find a file to copy in there
- try to copy it to your user directory

-> if the fix is doing its job, the copy should work without error

[ Proposed fix ]

Cherry-pick upstream commit 44edc3829d6db3fabe22d837eaaf2638003516c9 to fall back to g_file_query_info if query_info_on_read isn't supported.

[ Regression potential ]

Adds an extra step into file copying over gvfs. Check all previous gvfs copies still work.

[ Original report ]

Hello,

on Saucy I can't copy files from my digital camera to my PC anymore via file manager. This is a serious regression since it worked on all previous version of Ubuntu since Lucid at least (even earlier versions not tested because I didn't own the camera at that time).

It is easy to reproduce:
- Start PC from USB stick with current Saucy daily live image
- Connect and turn on camera
- Open Nautilus, browse the files on the camera, select one of them and right-click -> copy
- Now when I try to paste the file into my home directory, I get an error dialog saying copying failed with the reason "Operation not supported by backend" (see attached screenshot)

I get the same error message if I try to copy the file on terminal with the command gvfs-copy.

However, if I try to copy a file on terminal with the gphoto2 tool, e.g. 'gphoto2 --get-file 1', this works.

It also works if I copy files with cp in a terminal from gvfs-mountpoint mounted at /run/user/my_userid/gvfs/my_camera_mountpoint .

Kind regards,
Jan

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: libgphoto2-6 2.5.2-0ubuntu5
ProcVersionSignature: Ubuntu 3.11.0-3.8-generic 3.11.0-rc6
Uname: Linux 3.11.0-3-generic x86_64
ApportVersion: 2.12.1-0ubuntu2
Architecture: amd64
CasperVersion: 1.336
Date: Tue Aug 27 07:18:22 2013
LiveMediaBuild: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130826)
MarkForUpload: True
SourcePackage: libgphoto2
UpgradeStatus: No upgrade log present (probably fresh install)
---
ApportVersion: 2.12.1-0ubuntu3
Architecture: amd64
DistroRelease: Ubuntu 13.10
InstallationDate: Installed on 2013-08-02 (34 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha amd64 (20130802)
MarkForUpload: True
Package: gvfs 1.17.90-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 3.11.0-4.9-generic 3.11.0-rc7
Tags: saucy
Uname: Linux 3.11.0-4-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo

[markm (markm-redhat-bugs)]

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 ).

[Jeff (jeff-redhat-bugs)]

Created attachment 776906
screenshot of error message

"Me too..."

Here's a screenshot showing the error. Marking with a priority of "high" due to wife grief factor ;).

[Paul (paul-redhat-bugs)]

Ditto.

Opening the files directly in various editing packages and there is no issue.

[Cornelia (cornelia-redhat-bugs)]

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.

[Jan Rathmann (kaiserclaudius)]

I forgot to mention, camera is a Canon Powershot S5 IS .

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1217230

[Jan Rathmann (kaiserclaudius)]

According to bug reports in Debian and Fedora this is a Gvfs bug, so I reassign the bug to that package.

[Jan Rathmann (kaiserclaudius)]

apport information

[Jan Rathmann (kaiserclaudius)]

apport information

[smanocch (smanocch-redhat-bugs)]

Same problem with canon 50d

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[lendis (zakirovr90)]

New Ubuntu, old bug. Awesome

[Denis (denis-redhat-bugs)]

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.

[Denis (denis-redhat-bugs)]

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]

[Ejner (ejner-redhat-bugs)]

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.

[Ondrej (ondrej-redhat-bugs)]

Probably connected with:
https://bugzilla.gnome.org/show_bug.cgi?id=706254

[Hotteterre (luca-rossetto)]

After upgrading to Saucy, I'm experiencing the same error when trying to copy files from an audio CD to the hard disk. This occurs on two different computers!
Should I open a new bug report?

[Jan Rathmann (kaiserclaudius)]

@Hotteterre
Upstream bug report https://bugzilla.gnome.org/show_bug.cgi?id=706254 hints the assumption that this bug is not depended on any particular gvfs protocol. So I would assume at the moment that your bug is another manisfestation of the bug reported here, thus it is not necessary to create a separate report.

[Sebastien Bacher (seb128)]

Upstream has been pinged about the issue, let's see what they say about it

[Jan Rathmann (kaiserclaudius)]

A patch from upstream (for glib2.0) has recently been posted here: https://bugzilla.gnome.org/show_bug.cgi?id=706254#c12

I have build a new libglib2-version with this patch applied, and it seems to fix the bug for me.

I am preparing a PPA with the updated packages, so others can also test the fix easily.

Kind regards,
Jan

[Jan Rathmann (kaiserclaudius)]

PPA for testing the upstream patch is ready: https://launchpad.net/~kaiserclaudius/+archive/glib2.0bugfixtest

[Hotteterre (luca-rossetto)]

Thank you, Jan! I installed your patched package, and now all is perfect!

[Steve Langasek (vorlon)]

Hello Jan, or anyone else affected,

Accepted glib2.0 into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/glib2.0/2.38.1-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Jan (jan-redhat-bugs)]

(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?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[AgeR (h-reistenbach-3)]

I just installed the file from the PPA given above , and it works nice for my camera.

(Version 2.38.0-1ubuntu2 from https://launchpad.net/~kaiserclaudius/+archive/glib2.0bugfixtest)

[Iain Lane (laney)]

Could you please try the package from saucy-proposed instead? Steve gave instructions in a previous comment.

AgeR <email address hidden> wrote:

>I just installed the file from the PPA given above , and it works nice
>for my camera.
>
>(Version 2.38.0-1ubuntu2 from
>https://launchpad.net/~kaiserclaudius/+archive/glib2.0bugfixtest)
>
>--
>You received this bug notification because you are a bug assignee.
>https://bugs.launchpad.net/bugs/1217230
>
>Title:
> [Regression] Can't copy files from digital camera (Operation not
> supported by backend)
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/gvfs/+bug/1217230/+subscriptions
>

[Jan Rathmann (kaiserclaudius)]

The glib version 2.38.1-0ubuntu1 that has been uploaded to saucy-proposed fixes the bug for me, many thanks to the uploaders!

[Jan Rathmann (kaiserclaudius)]

I have also added a message to the PPA that affected users should use the package updates from saucy-proposed instead.

[Silvan Wehrli (silvan-wehrli)]

I had the same issue, but the glib from saucy proposed fixed it for me as well. Thank you very much.

Btw: I don't know if this problem is related to it, but if I right click in the digital camera folder and select "open in terminal", a terminal pops up quickly and is immediatly closed again. This only occurs in the camera folder, otherwise this feature works. If it doesn't relate to this problem, I will make another bug report.

[Launchpad Janitor (janitor)]

This bug was fixed in the package glib2.0 - 2.38.1-1

---------------
glib2.0 (2.38.1-1) experimental; urgency=low

  * Build-Depend on python:any
  * New upstream bugfix release 2.38.1
    + Fix error code checks when SOCK_CLOEXEC is defined but not supported
      (fix support for GNU/Hurd)
    + g_settings_list_children: only list viable schemas (fix gsettings
      list-recursively crashes with invalid schemas installed)
    + GDBusObjectManagerClient: Fix typo in the /org/freedesktop/DBus path
      when adding match rules
      - Remove 0001-gio-Fix-typo-in-the-org-freedesktop-DBus-path.patch
  * 0001-g_file_copy-Fall-back-to-pathname-queryinfo-to-help-.patch:
    Cherry-pick gio patch to fall back to g_file_query_info if
    query_info_on_read is not supported. Fixes copying from backends that
    don't implement the latter. (Closes: #715436, LP: #1217230)

 -- Iain Lane <email address hidden> Thu, 17 Oct 2013 15:53:12 +0100

[Hotteterre (luca-rossetto)]

I tried the package in Saucy proposed: perfect!
Thanks to you all!

[Ian Stoner (ston0235)]

The package in Saucy proposed fixed this problem for a Canon Digital Rebel xti. Thank you!

[Steffan Karger (syzzer)]

I stumpled upon the same issue. For me too the glib2.0{-bin,-0) packages from saucy-proposed fixed the problem.

For other users: I had to log out and in before copying worked. Killing/restarting the right processes probably works too.

[Christian Prim (christian-prim)]

It fixes also my problem, not beeing able to copy files from a afp-share. Thanks!

[Panu (panu-redhat-bugs)]

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.

[Trucoto (trucoto)]

Did not work for me with my Canon DSLR; tried proposed and it fixed it. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package glib2.0 - 2.38.1-0ubuntu1

---------------
glib2.0 (2.38.1-0ubuntu1) saucy; urgency=low

  * New upstream bugfix release 2.38.1 (LP: #1241083)
    + Fix error code checks when SOCK_CLOEXEC is defined but not supported
      (fix support for GNU/Hurd)
    + g_settings_list_children: only list viable schemas (fix gsettings
      list-recursively crashes with invalid schemas installed)
    + GDBusObjectManagerClient: Fix typo in the /org/freedesktop/DBus path
      when adding match rules
      - Remove 0001-gio-Fix-typo-in-the-org-freedesktop-DBus-path.patch
  * 0001-g_file_copy-Fall-back-to-pathname-queryinfo-to-help-.patch:
    Cherry-pick gio patch to fall back to g_file_query_info if
    query_info_on_read is not supported. Fixes copying from backends that
    don't implement the latter. (Closes: #715436, LP: #1217230)
 -- Iain Lane <email address hidden> Thu, 17 Oct 2013 17:49:34 +0100

[Brian Murray (brian-murray)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Wade (wade-redhat-bugs)]

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.

[David (david-redhat-bugs)]

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

[Richard (richard-redhat-bugs)]

Fails to me too, Fedora 19.

[Richard (richard-redhat-bugs)]

I've added that patch to the Fedora 19 glib2 package.

[Fedora (fedora-redhat-bugs)]

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

[Fedora (fedora-redhat-bugs)]

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).

[Richard (richard-redhat-bugs)]

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.

[Panu (panu-redhat-bugs)]

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!

[Fedora (fedora-redhat-bugs)]

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.

[David (david-redhat-bugs)]

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.