Description of problem: When you plug in a Samsung Galaxy S III phone, a directory appears in /run/user/jgotts/gvfs: "gphoto2 mount on usb%3A003,010", for example. The final three digits appear to be incremented according to some scheme. This follows immediately after plugging in the phone. I am in in the /run/user/jgotts/gvfs directory. [jgotts@jeglap gvfs]$ cd gphoto2\ mount\ on\ usb%3A003\,010/ [jgotts@jeglap gphoto2 mount on usb%3A003,010]$ ls store_00010001 store_00020002 [jgotts@jeglap gphoto2 mount on usb%3A003,010]$ cd store_00010001/ [jgotts@jeglap store_00010001]$ ls ls locks up for several minutes and then outputs the following line: ls: reading directory .: Input/output error [jgotts@jeglap store_00010001]$ pwd /run/user/jgotts/gvfs/gphoto2 mount on usb%3A003,010/store_00010001 [jgotts@jeglap store_00010001]$ cd /run/user/jgotts/gvfs [jgotts@jeglap gvfs]$ ls gphoto2 mount on usb%3A003,010 [jgotts@jeglap gvfs]$ cd gphoto2\ mount\ on\ usb%3A003\,010/ [jgotts@jeglap gphoto2 mount on usb%3A003,010]$ ls store_00010001 store_00020002 [jgotts@jeglap gphoto2 mount on usb%3A003,010]$ cd store_00010001/ [jgotts@jeglap store_00010001]$ ls ls again locks up for several minutes and then outputs: ls: reading directory .: Input/output error After these two very long timeouts, the phone becomes accessible. In order to absolve Rhythmbox of any responsibility for this issue, I turned off starting programs on media insertion. This bug does cause Rhythmbox to lock up for a few minutes before not being able to see any files on the phone. Trying to get properties of the phone then results in this seg fault: (rhythmbox:5110): GLib-GObject-CRITICAL **: g_type_instance_get_private: assertion `instance != NULL && instance->g_class != NULL' failed Segmentation fault (core dumped) On a side note, why does Rhythmbox start? All types of media are set to "Ask what to do". What sets Rhythmbox as the player? I don't ever want to use it, but I do want to be able to choose something else. (No offense intended to the Rhythmbox author.) Another interesting bug. Every file on the filesystem is dated at the beginning of UNIX time. Perhaps this is a deficiency in the protocol. [jgotts@jeglap store_00010001]$ ls -la total 555 drwx------ 1 jgotts jgotts 0 Dec 31 1969 . drwx------ 1 jgotts jgotts 0 Dec 31 1969 .. ... drwx------ 1 jgotts jgotts 0 Dec 31 1969 Android Version-Release number of selected component (if applicable): 1.12.3-1.fc17 How reproducible: Always. Steps to Reproduce: 1. Plug in a Samsung Galaxy S III phone (and probably many similar phones) 2. Try to access the contents of the phone with ls. 3. Actual results: Two very long timeouts will occur, and hopefully afterwards you will be able to access files on the phone. Expected results: There should be no timeouts. The phone should work similarly to a USB storage device, and it would be nice if every file wasn't timestamped to be the beginning of UNIX time. Additional info:
I unplugged my phone and got this (from the /run/user/jgotts/gvfs directory): [jgotts@jeglap gvfs]$ ls gphoto2 mount on usb%3A003,011 [jgotts@jeglap gvfs]$ cd gphoto2\ mount\ on\ usb%3A003\,011/ [jgotts@jeglap gphoto2 mount on usb%3A003,011]$ ls store_00010001 store_00020002 [jgotts@jeglap gphoto2 mount on usb%3A003,011]$ cd store_000 bash: cd: store_000: No such file or directory [jgotts@jeglap gphoto2 mount on usb%3A003,011]$ cd store_00010001/ [jgotts@jeglap store_00010001]$ ls A delay of several minutes. ls: reading directory .: Input/output error [jgotts@jeglap store_00010001]$ ls A delay of several minutes. ls: reading directory .: Input/output error [jgotts@jeglap store_00010001]$ ls Another delay of a couple minutes, and then ls proceeds.
Apparently, before you can access files on the phone, libmtp does the equivalent of an "ls -laR" on the entire phone. For my phone that takes somewhere on the order of 5-10 minutes. http://intr.overt.org/blog/?p=153 "The most common flaw is that the tools use an MTP library call that attempts to enumerate the entire device filesystem in one go. This causes the initial connection to be very slow, and on the newest Android devices, it flat out doesn’t work, as the phone end will timeout the operation before it completes. This ends up taking out every single tool on the market (including: mtpfs, gmtp, banshee, rhythmbox, gvfs gphoto2 backend) except for one: go-mtpfs." So the solution might be to switch to gvfsd-mtp?
Ubuntu fixed this bug just two weeks ago: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422 Seems like Fedora just needs to merge some patches.
(In reply to comment #0) > Description of problem: > When you plug in a Samsung Galaxy S III phone, a directory appears in > /run/user/jgotts/gvfs: "gphoto2 mount on usb%3A003,010", for example. The > final three digits appear to be incremented according to some scheme. Note that gvfs-fuse is just a fallback for POSIX applications and should not be used seriously. Use GIO directly. > ls locks up for several minutes and then outputs the following line: > > ls: reading directory .: Input/output error Try to reproduce with GIO directly, i.e. use gvfs-* commands on the mount. > (rhythmbox:5110): GLib-GObject-CRITICAL **: g_type_instance_get_private: > assertion `instance != NULL && instance->g_class != NULL' failed > Segmentation fault (core dumped) --> please file a bug on Rhythmbox > Another interesting bug. Every file on the filesystem is dated at the > beginning of UNIX time. Perhaps this is a deficiency in the protocol. Please check gvfs-info on the mount, it's possible that the attribute is unavailable and not set. Not every backend provides all the information. > Expected results: > There should be no timeouts. The phone should work similarly to a USB > storage device, and it would be nice if every file wasn't timestamped to be > the beginning of UNIX time. FYI, the gphoto2 backend has been replaced by new libmtp-based in rawhide which should provide better compatibility. Testing that would be appreciated, we're not going to backport it to already released Fedora versions though. Also, please check if there were any crashes (dmesg, abrt) or if it's just a gphoto2 issue. (In reply to comment #3) > Ubuntu fixed this bug just two weeks ago: > > https://bugs.launchpad.net/ubuntu/+source/udev/+bug/903422 > > Seems like Fedora just needs to merge some patches. The discussion is very long, could you please post a solution here?
> Try to reproduce with GIO directly, i.e. use gvfs-* commands on the mount. There isn't any documenation for gvfs-ls or gvfs-cat. I had no idea what these programs were or what they were supposed to do. [jgotts@jeglap /]$ mount ... gvfs-fuse-daemon on /run/user/jgotts/gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000) [jgotts@jeglap /]$ cd /run/user/jgotts/gvfs [jgotts@jeglap gvfs]$ gvfs-ls gphoto2 mount on usb%3A002,008 cdda mount on sr0 [jgotts@jeglap gvfs]$ cd gphoto2\ mount\ on\ usb%3A002\,008/ [jgotts@jeglap gphoto2 mount on usb%3A002,008]$ gvfs-ls store_00010001 store_00020002 [jgotts@jeglap gphoto2 mount on usb%3A002,008]$ cd store_00010001/ [jgotts@jeglap store_00010001]$ gvfs-ls [Hangs for a long time.] Error: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [jgotts@jeglap store_00010001]$ gvfs-ls [Hangs for a long time.] Error: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. [jgotts@jeglap store_00010001]$ gvfs-ls [Functions.] So if rawhide does the equivalent of using gvfs-ls it won't work, either.
(In reply to comment #5) > There isn't any documenation for gvfs-ls or gvfs-cat. I had no idea what > these programs were or what they were supposed to do. Manpages have been added in gvfs-1.13.3, another reason for switching to F18 at least :-) Basically `gvfs-mount -l` would give you list of active mounts and URIs for every one. That could be used with other utilities, e.g. `gvfs-ls gphoto2://[00:11:22]/Android/`. Forget about fuse now, we need to find out where the problem is, it's just an additional layer that could introduce bugs.
According to the Ubuntu bug report, glib upstream was switched to this other library, so the solution should be to add that library and upgrade glib. I'm okay with you NOT patching production with this behavior. This change is too radical for that kind of thing. I can help test what you come up with on rawhide. The reason why this bug hasn't shown up much so far is that most people don't install a lot of programs on their phones or in general don't have a lot of data there. In a few years people will start using several of the 8 or 16 gigabytes available. This "recursive ls" will take 10 minutes on many phones and binaries will segfault if they don't handle the error conditions correctly. In general, though, we want a camera that's plugged in to be immediately accessible as with USB storage. The low-level camera interface should only look in the "current directory" and not try to obtain the contents of the entire phone before it starts working. The timeout behavior exists for everybody with new Android phones, all phones running Android 4.1. Also of note: Just for grins I switched the phone from MTP mode to PTP mode. shotwell picked some random directory and found only the 7 photos there, instead of the hundreds of photos I have in various subdirectories. So it looks like shotwell or its underlying libraries will need to be fixed for it to be able to properly support Android phones.
I'm pretty sure that gvfs is trying to enumerate every file on the device. Do you have reason to believe that the 10 minute timeout is something else?
The behavior has worsened recently. Not sure what triggered it. [jgotts@jeglap ~]$ cd /run/user/jgotts/gvfs [jgotts@jeglap gvfs]$ ls gphoto2 mount on usb%3A003,004 [jgotts@jeglap gvfs]$ cd gphoto2\ mount\ on\ usb%3A003\,004/ [jgotts@jeglap gphoto2 mount on usb%3A003,004]$ ls store_00010001 store_00020002 [jgotts@jeglap gphoto2 mount on usb%3A003,004]$ cd store_00010001/ [jgotts@jeglap store_00010001]$ ls [Several minutes of waiting.] ls: reading directory .: Input/output error [jgotts@jeglap store_00010001]$ ls [Directory listing omitted.] [jgotts@jeglap store_00010001]$ cd Download/ [jgotts@jeglap Download]$ ls [Directory listing omitted.] [jgotts@jeglap Download]$ less Wheatus-Teenage-Dirtbag.mp3 [Several minutes...] Wheatus-Teenage-Dirtbag.mp3: Input/output error [jgotts@jeglap Download]$ less Wheatus-Teenage-Dirtbag.mp3 [Several minutes...] Wheatus-Teenage-Dirtbag.mp3: Input/output error [jgotts@jeglap Download]$ mpg321 Wheatus-Teenage-Dirtbag.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2, and 3. Version 0.2.13-2 (2011/03/27). Written and copyrights by Joe Drew, now maintained by Nanakos Chrysostomos and others. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Wheatus-Teenage-Dirtbag.mp3: Input/output error tcsetattr ICANON: Invalid argument [jgotts@jeglap Download]$ No files on my Samsung phone are accessible anymore, even after long timeouts trying to look at the files.
#9 went away. There was some bad update that was corrected. The ten minute delay still occurs.
#9 returned again. I can't access a single file on my phone. I'll start looking into merging the changes that Ubuntu has done. No ETA on when I will finish that process, or even whether I will finish it.
I did some additional research on this today. https://launchpad.net/ubuntu/+source/gvfs/1.15.2-0ubuntu1 indicates that the necessary fixes are in gvfs 1.15.2. 1.16.0 is in rawhide, so I imagine that Fedora 19 will work once it is released. The other solution is to create a subdirectory in your home directory and run: simple-mtpfs <subdirectory> and fusermount -u <subdirectory> when you're done. This solution loses auto-mounting capabilities but it does work. You'll need to install the simple-mtpfs package. You have to be careful to avoid certain operations. For example, audacious *.mp3 in your MP3 directory will freeze the application for several minutes while it tries to obtain track information. audacious should be changed to retrieve this information on demand.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.