Skip to content

GVFS MTP Updates: Direct I/O and filenames in URIs!

Hi Everyone,

It’s been a while since my last update (over a month!) so it’s a good time to talk about what’s been going on.

Firstly, GVFS 1.16 is out – so that’s the first stable release with the MTP backend in it. w00t!

Before you wonder, it doesn’t include my work to support the Android Direct I/O extensions (that allow normal read/write access to files on the device). I’ve now got those to a point where I’m ready to get them in, but I’m waiting on a review in bugzilla. Since my last update, all the libmtp changes have been merged and released in version 1.1.16.

The second big thing I’ve done is completely change how mtp URIs work. In previous posts, I’ve talked about how I was putting entity IDs as path elements to save having to maintain an ID->filename mapping, and then relying on the gvfs display and copy name properties to make the files appear to have normal names when looked at. I ultimately decided to abandon this approach for a couple of reasons. The main one is that with Direct I/O support, every application that can operate on files can be used with an MTP device, and most of those apps don’t know anything about gvfs and can’t use the special properties. The second reason is that there are edge cases where it’s impossible to tell if you’re looking at a filename that’s all numbers or an entity ID. So, I’ve added a mapping system and URIs now use filenames.

Finally, I’ve fixed a bug in gvfs that only got triggered when unmounting an mtp device in Ubuntu 13.04 betas. The code in question hasn’t changed in gvfs for a long time, but the bug didn’t appear anywhere else. Still, there is a real code problem in there, so I’ve got a fix out for it.

I’ve updated my with builds that contain all these pending patches (although the raring gvfs got updated while mine was building so it’s now considered out-of-date) and the new libmtp, so please try the new stuff out.

For the curious, here are the GNOME bugzilla entries tracking these changes:

Enjoy!

{ 14 } Comments

  1. Jorge | 24th April 2013 at 01:30 | Permalink

    Just updated from your PPA my Ubuntu raring install. All regular applications can access the files in my MTP device (Samsung Galaxy S – i9000) seamlessly. It is nice to be able to edit my text files with gedit or vi ringht on the device. So a big thanks for your great work.

    I see very little chance that your I/O updates make to the final Ubuntu 13.04 release though.

    jorge.

  2. Philip Langdale | 24th April 2013 at 07:57 | Permalink

    No, it’s definitely not going to make it into 13.04, so you’ll have to keep using the ppa until 13.10

  3. unludo | 14th July 2013 at 12:19 | Permalink

    I have this issue when mounting my Samsung S3 after I installed GVFS:

    Unable to open MTP device ‘[usb:001,003]‘

    Is it related to GVFS? Do you know what I should do?

    Thank you

  4. Philip Langdale | 14th July 2013 at 12:29 | Permalink

    Did you plug your phone into a USB3 port? Older Samsung devices are simply not reliable when plugged into one.

  5. Richard L | 6th August 2013 at 01:38 | Permalink

    The gvfs released with 13.04 no longer allows you to access WALKMAN’s (MTP devices) as if they were a Mass Storage Device. Can they be mounted manually?

  6. Philip Langdale | 6th August 2013 at 08:06 | Permalink

    Hi Richard,

    What makes you think it could work as an MSC device? This is typically not something the computer can control – it’s a device side setting. It’s more likely that you were previously connecting using gvfs-gphoto2 – which is what was used for MTP devices prior to 13.04. In that situation it was using the PTP subset of MTP.

    There are changes to how gvfs mounts are handled in Nautilus in 13.04. One example is that per-user mounts now appear in /run/user//gvfs/ instead of under /media.

    As for the strange filenames-as-numbers – that’s how it works in the version of gvfs-mtp shipped in 13.04. In 13.10 it will use normal filenames (or you could use my ppa to get a newer version). You did not specifically state you had problems accessing the files themselves. I assume you can?

  7. Richard L | 6th August 2013 at 10:45 | Permalink

    Hi Philip,

    You new ppa was a big help, so thanks.

    My aim is to rsync between a copy of the files held locally and those on the device itself, however I get the following errors:
    rsync: failed to set times on … Operation not supported (95)
    rsync: mkstemp … Operation not supported (95)

    Should this be possible, will it be possible in the near future?

    Thanks.

  8. Philip Langdale | 6th August 2013 at 19:39 | Permalink

    I’m glad the PPA worked for you.

    In general, a comprehensive rsync process isn’t going to be possible. As I’ve discussed in various blog posts, MTP doesn’t physically support the low level operations you need to make it work effectively – unless you’re using Google’s MTP stack, which a walkman obviously isn’t.

    It might be possible to get a strict one-way sync (PC to device) to work in an rsync like way but with full file writes (no block writes possible) but it would need to be written as a native gvfs client. You’re better off doing a size/data comparison and replacing files on that basis – and that’s what Sony’s native tools would do – no rsync block checksums going on!

    Now, you’re probably going to tell me that this worked before, and it’s true that gvfs-gphoto2 appears to offer normal filesystem operations but it’s all a facade, as discussed elsewhere, and it’s constantly copying files to/from /tmp when you think it’s just reading and writing. This process is fragile and not something I would endorse. But if you really want to use rsync, it’s the only way. I’d recommend using go-mtpfs in that case or adding a udev rule to avoid marking the walkman as an MTP device so that gvfs-gphoto2 gets used again.

  9. Levab | 4th November 2013 at 03:11 | Permalink

    Can you add support of 13.10 because without?? your ppa my walkman does not work.

  10. Philip Langdale | 4th November 2013 at 07:49 | Permalink

    13.10 contains all of the work I did. There’s nothing in the PPA that isn’t already in it.

  11. Levan | 4th November 2013 at 12:51 | Permalink

    @Philip Langdale

    Thank you for the reply,

    Well after adding your software to 13.04 and creating a file /etc/udev/rules.d/10-local.rules and adding {idVendor} and {idProduct} I could use my walkman but on 13.10 it does not work out of the box neither does after doing the same steps as I would do on 13.04 it did not work.

    I know I am bothering you and most probably you are fed up by answering to all this questions So I understand and if you do not reply it is good with me :)

  12. Philip Langdale | 4th November 2013 at 12:56 | Permalink

    This is likely due to general changes in the udev rules in 13.10, rather than anything specific to the code. Are you trying to make the walkman work with gvfs-mtp or gvfs-gphoto2? You should look at the ptp and mtp rules files in 13.10 and see how they might affect your device. For example, there may be a new entry for it that wasn’t there in 13.04 which is causing a new rule to override yours (remember, you put yours at priority 10, so it will run before the standard rules files).

  13. Levan | 4th November 2013 at 13:17 | Permalink

    https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1183948/comments/5

    This is how i did it sorry for not hawing a lot of technical knowledge

  14. Philip Langdale | 5th November 2013 at 12:42 | Permalink

    Well, I don’t think that rule does anything useful. it just assigns a friendly name to the device. It doesn’t change how it gets detected by mtp/ptp or anything else that’s relevant to gvfs. If mtp-detect returns positive results for the device, it will be handled by gvfs-mtp. There’s also a ptp detection rule file for udev. if that’s positive and mtp isn’t, then it’ll get handled by gvfs-gphoto2

Post a Comment

Your email is never published nor shared. Required fields are marked *