After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 773824 - Inability to use FUSE for Android MTP from POSIX (non-libgio) apps
Inability to use FUSE for Android MTP from POSIX (non-libgio) apps
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: fuse
1.22.x
Other Linux
: Normal normal
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2016-11-02 11:12 UTC by Michal Rus
Modified: 2018-09-21 18:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michal Rus 2016-11-02 11:12:03 UTC
After connecting an Android phone, I can copy/move/paste/… files present on it in Nautilus/Thunar/… However, it’s impossible to upload a photo from, say, Chrome or Firefox, directly from said phone.

This is a major use case for my mother, as I learned today.

It’s probably due to the fact, that FUSE mount for MTP devices does not implement all syscalls that are needed… E.g. I can list files, but not read from them:

% ls /run/user/1000/gvfs/mtp…/Phone/Camera/photo.jpg
-rw------- 1 m users 62022 Oct  4 20:54 photo.jpg
% cp /run/user/1000/gvfs/mtp…/Phone/Camera/photo.jpg ~/photo.jpg
cp: cannot open ‘photo.jpg’ for reading: Operation not supported
%

For comparison, jmtpfs — https://github.com/kiorky/jmtpfs — works perfectly and is emulating the needed syscalls, so clearly, this is doable.

jmtpfs is what I’m using, but I cannot make my mother use CLI…

Help? :-)
Comment 1 Ondrej Holy 2016-11-02 12:58:53 UTC
This should be supported by gvfs for devices with android extensions. Obviously your devices don't support them...

Yes, it is doable... but the following is a bit scary:
https://github.com/kiorky/jmtpfs/blob/master/README#L74

The files needs to be cached somewhere - in mtp backend, in fuse daemon, or somewhere else. I proposed file caching, which might fix this issue, before quite a long time, but I have never merged it due to lack of time:
https://bugzilla.gnome.org/show_bug.cgi?id=728375

The caching can solve some issues, however it can also cause another ones. Open job can take too much time, it can consume a lot of space, progress is reported wrongly.

But you are right that we should take a look at it again...
Comment 2 kolAflash 2017-04-10 18:45:38 UTC
Looks like I'm having the same problem with a Nokia E72 (running Symbian S60 3rd edition).
Tested gvfs-1.28 on openSUSE 42.2 and gvfs-1.32 on openSUSE Tumbleweeg GNOME Snapshot-20170406.

I guess this is about the "get object" and "get partial object" MTP commands!?
So trying a "get partial object" is resulting in the "Operation not supported" message.

What about a fallback after fail. Instead of reporting "Operation not supported" at read, GVFS could just try "get object" before giving up and remember that after it happened once for a mountpoint.
Same for writing files.

Alternatively GVFS could try to detect the devices capabilities on mount. But I'm just experiencing, that this might also not always work. At least "simple-mtpfs" should autodetect, but it's always falling back to "get object", even if the device (tried a brand new Android) definitely has "get partial object".

Interesting thing I found by the way:
Nautilus is actually able to copy files from the device.
I guess because Nautilus isn't accessing files on mtp devices via filesystem/fuse but via an direct API to GVFS, which tells GVFS to use "get object" for whole files.
Sadly I need to use some other Programs that Nautilus to access files on the Nokia E72 phone regularly :-/
Comment 4 Ondrej Holy 2017-04-11 07:22:16 UTC
It works more-or-less as you told. I hope I will find some time to improve FUSE support in this development cycle...
Comment 5 GNOME Infrastructure Team 2018-09-21 18:03:40 UTC
-- 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/291.