Hmm? Is this with 8.1? I don't see it with my devices. In charging mode, there is no MTP presence and when it switches to file transfer, it then appears.

On the other hand, when you go back to Android 6, file transfer was available by default, but the storage was protected by the screen lock, so you would get a mount with no storages until you unlock the screen, then they appear. That's the expected behaviour (it matches what windows does).

If that's happening again with 8.1, I would still call it correct behaviour.

Yes, with 8.1. The problem is that volume/mount is re-created after switching to MTP mode:

Volume added:       'Nexus 5X' <- plugging in
Mount added:        'mtp'
Mount changed:      'mtp'
Mount added:        'Nexus 5X'
Mount changed:      'Nexus 5X'
Volume removed:     'Nexus 5X' <- switching to mtp mode
Mount removed:      'Nexus 5X'
Mount changed:      'mtp'
Mount removed:      'mtp'
Volume added:       'Nexus 5X'
Mount added:        'mtp'
Mount changed:      'mtp'
Mount added:        'Nexus 5X'
Mount changed:      'Nexus 5X'

mtp: (II) get_device_info done with no stores.

What do you think about implementing of the similar behavior as gphoto2volumemonitor has? Do not add the volume unless LIBMTP_Get_Storage returns something. It should work also with Android 6 if event loop will be implemented...

Does it actually break? or is it just annoying that you open a Nautilus window, see it's empty, then change the device mode, then the window disappears, and you have to open it again?

My concern is that currently the monitor does not know, or need to know, any MTP. Only one process can talk to an MTP device at a time, and bad things happen if two try to do it, as you may know. I'd worry about coordinating monitor and backend operations if the monitor is trying to evaluate the device. I'd rather leave things the way they are, but i haven't seen the behaviour myself; I'm still running 8.0 here.

It is annoying and may be confusing for some people. 

I am aware of problems with multiprocess access to MTP devices, but GPhoto2 has the same limitations, doesn't have? The monitor interaction with the device has to happen only before adding new volume (i.e. before mounting) in order to avoid multiprocess access.

The failure scenarios are, in my experience, different between mtp and ptp. I fairly often see situations where we cannot cleanly release and reacquire a device (unmount and remount, or unmount and run mtp-detect, etc). So I worry greatly that if the monitor opens it, then we try to mount, the mount is more likely to fail (after a long timeout, to add insult to injury).

Because the monitor is long lived and singular, I don't want it to get into some failed state that then breaks all device detection. It's much easier to restart the mount process than the monitor.

What about erroring out of the mount process with a message saying the device needs to be put into MTP mode or unlocked? At least then we keep the MTP accesses out of the monitor.

Errors during mount process are not probably a good idea as well, because an error will be printed everytime you connect the phone due automount (which is by default enabled) and because charging is selected on the phone by default... let's ignore this report for now and will see what happens after other devices got android updates (it might be also bug in Android)...

I would like to think it's a bug; maybe try and report it to Google? :-)

I saw something that may have been this same behaviour happen to me once on my phone, where it would appear in MTP when in charging mode, but it went away after a reboot.

I've made the following post in Android Beta Program community:
https://plus.google.com/116468128122919226047/posts/bL81XJptotF

I finally realised why we see different behaviour. When you turn USB debugging on, the device identifies itself in a distinct mode where MTP is not exposed. When debugging is off, it identifies itself as an MTP device whether you put it in file transfer mode or not.

I couple of observations - if we abort in do_mount(), I don't see any error popup - this surprised me, but there you go.

We could also return G_IO_ERROR_FAILED_HANDLED which tells the client that we've already communicated the error to the user (which is a lie, but good enough).

I also noted the following in the log:

Nov 10 08:17:58 fido6 gvfsd[1735]: mtp: (II) get_device: Storing device [usb:003,026]
Nov 10 08:17:58 fido6 gvfsd[1735]: Error 1: Get Storage information failed.

The call to LIBMTP_Open_Raw_Device_Uncached() is generating that error in the MTP error stack. It doesn't return an error to us, which is unfortunate, but if we can detect this case, we have a clear indicator of when we have a device in this 'broken' mode. Of course, I don't have an android 6 device anymore to test what happens in the old locked case. If this error happened there too, then it doesn't help us.

I don't think that silently abort mounting is a good idea because volume still exists and you don't get any feedback when mounting manually...

So, I had a thought. I think that if we changed our uri pattern so that it didn't change on every replug, we might have a solution. Because the switch to mtp mode would stay on the same uri and any open nautilus windows should update correctly. That would also address bug 744267 :-)

Created attachment 366463 [details] [review]
Switch to a stable device URI

A first attempt at implementing stable URIs.

Sorry for the delay, see my comment on Bug 744267.

-- 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/318.