libmtp error when attempting to write to root of internal storage

Bug #1368868 reported by Jonathan Cave on 2014-09-12
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Canonical System Image
Wishlist
Unassigned
libmtp (Ubuntu)
Undecided
Unassigned

Bug Description

Version: ubuntu-rtm r32

Steps to reproduce:
 * connect the device to an Ubuntu desktop via USB
 * open the device in the file manager
 * enter the internal storage (krillin folder)
 * attempt to copy a file to the device

Expected result:
 - file is written

Actual result:
 - ugly dialog presented to user

Jonathan Cave (jocave) wrote :
John McAleely (john.mcaleely) wrote :

It would seem reasonable for a 'better error' to be the expected result, depending on the design. something like 'this folder is read only'.

As it stands, niave users copy stuff to their krillin, and get an obscure error message. Seems bad to me.

Changed in barajas:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Pat McGowan (pat-mcgowan)
milestone: none → m27
tags: added: rtm14
Pat McGowan (pat-mcgowan) wrote :

@mathieu do we have enough info to report a better message?

Changed in barajas:
assignee: Pat McGowan (pat-mcgowan) → Mathieu Trudel-Lapierre (mathieu-tl)
tags: added: usability
tags: added: touch-2014-10-09
Changed in barajas:
milestone: m27 → m29

We do; I'm just not sure whether there *is* a better message to display. Will investigate and propose a fix.

Changed in barajas:
status: Confirmed → In Progress

I have a possible fix; but Ubuntu doesn't differentiate enough between the various errors coming from MTP. That's an issue that needs to be fixed in libmtp; and that possibly also exists on Windows depending on how far they go into parsing the MTP errors.

There are workarounds however. We could display all of the home directory for the user and then not require any special code to write-protect the home directory, which is what the root of the storage maps to. That however, defeats the initial intent of avoiding to expose files as much as possible. It's not necessarily *that* bad however, given that for normal usage, there shouldn't be files in the home directory besides hidden files and folders (which we can still hide).

Another options is to generate separate local storage "drives" for each of Images, Photos, etc., but this increases complexity by a lot.

Changed in barajas:
assignee: Mathieu Trudel-Lapierre (mathieu-tl) → Pat McGowan (pat-mcgowan)
status: In Progress → Triaged
Pat McGowan (pat-mcgowan) wrote :

When trying to copy to the top directory the message is: "Cannot write to this location" which is much more helpful

tags: added: ota-2
removed: touch-2014-10-09
Pat McGowan (pat-mcgowan) wrote :

Pushing out to ota so we can figure out a proper improvement, for now its not blocking and is partly dependent on the host side implementtion

Changed in barajas:
milestone: m29 → none
Changed in barajas:
importance: High → Wishlist
assignee: Pat McGowan (pat-mcgowan) → nobody
tags: removed: ota-2 rtm14
information type: Embargoed → Proprietary
affects: barajas → avila
information type: Proprietary → Public
affects: avila → canonical-devices-system-image
Philip Langdale (langdalepl) wrote :

This was actually a gvfs issue, and it was fixed many years ago. The root of the device is now correctly marked as read-only.

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

Other bug subscribers