GVFS MTP paths are not stable

Bug #1419523 reported by Michael von Glasow
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gvfs
Fix Released
Medium
gvfs (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Every time I unplug my Android phone and reconnect it, its URL changes. E.g. when it is mounted as mtp://[usb:002,002]/ and I unplug and recoonect it, it gets a new URL, e.g. mtp://[usb:002,003]/.

This behavior breaks all use cases which depend on a stable path (e.g. shell scripts, synching via Unison etc.).

Is there any way to implement a behavior similar to removable drives? They get a consistent mounting path, which is /media/<user>/<name>, where <name> is either the volume label (if present) or the volume ID.

In GVFS this would require uniquely identifying MTP devices. If there is something as a volume ID, GUID or any other element that can uniquely identify a MTP device, this would be the way to go. If MTP doesn't provide this kind of ID (don't know if it does), then maybe "fingerprinting" the device (based on characteristics as the USB vendor & device IDs) may be a valid workaround.

Revision history for this message
Michael von Glasow (michael-vonglasow) wrote :

Doing some research, I found the MTP spec at:

https://msdn.microsoft.com/de-de/library/ms867188.aspx

Chapter 5.1.1 DeviceInfo Dataset specifies a Serial Number (5.1.1.14), which is "required to be unique among all devices sharing identical Model and Device Version fields". Thus every MTP device should be uniquely identifiable by the following fields from its DeviceInfo:

- Manufacturer
- Model
- Device Version
- Serial Number

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gvfs (Ubuntu):
importance: Undecided → Low
Revision history for this message
Michael von Glasow (michael-vonglasow) wrote :

I'll take care of that as soon as Bugzilla is back (currently down for a version upgrade).

Revision history for this message
Michael von Glasow (michael-vonglasow) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks

Changed in gvfs (Ubuntu):
status: New → Triaged
Changed in gvfs:
importance: Unknown → Medium
status: Unknown → New
Changed in gvfs:
status: New → Confirmed
Changed in gvfs:
status: Confirmed → Fix Released
Revision history for this message
Michael von Glasow (michael-vonglasow) wrote :

That’s great news! Will the fix still make it into 18.04 LTS?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.