RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1242190 - gvfs-mtp copies data to wrong storage location
Summary: gvfs-mtp copies data to wrong storage location
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gvfs
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Holy
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-12 03:06 UTC by Joshua Weage
Modified: 2015-11-19 09:29 UTC (History)
3 users (show)

Fixed In Version: gvfs-1.22.4-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 09:29:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
gvfsd log #1 (14.64 KB, text/plain)
2015-07-15 01:53 UTC, Joshua Weage
no flags Details
gvfsd log #2 (5.87 KB, application/x-gzip)
2015-07-15 01:53 UTC, Joshua Weage
no flags Details
"empty" sdcard and folder rename error (273.27 KB, image/png)
2015-07-15 01:53 UTC, Joshua Weage
no flags Details
"empty" sdcard and folder rename error (253.74 KB, image/png)
2015-07-15 01:56 UTC, Joshua Weage
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2106 0 normal SHIPPED_LIVE desktop core libraries bug fix and enhancement update 2015-11-19 09:34:35 UTC

Description Joshua Weage 2015-07-12 03:06:02 UTC
Description of problem:

After attaching an LG Volt phone via USB cable, the phone is recognized and the file browser shows internal and sdcard storage. Copying a folder to the sdcard storage location results in the files being written to the internal storage on the phone.

Version-Release number of selected component (if applicable):
1.6.4-8.el7.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Plug in phone.
2. Copy folder to sdcard.
3. Folder appears on phone internal memory.

Actual results:


Expected results:


Additional info:

Comment 2 Ondrej Holy 2015-07-14 11:44:00 UTC
Thanks for your bug report. 

I can't reproduce such behavioral. Are you able to reproduce the issue? Can you provide more info how to reproduce it? What file browser is used? What method is used to copy the file (drag and drop, keyboard shortcuts, context menu...)? What is location of the source file?

Please run following command if you are able to reproduce the issue:
GVFS_DEBUG=1 /usr/libexec/gvfsd --replace &> ~/gvfsd.log
Then plug your phone and copy the folder to sdcard as mentioned in your report. Finally please attach the gvfsd.log file from your home folder to the bug report.

Comment 3 Joshua Weage 2015-07-15 01:52:11 UTC
Yes, I am able to reproduce the problem.

With the original sdcard, I copied the files to the phone using Windows. After plugging the phone back into my linux workstation today, it appears to work correctly with new files being copied to the external sd card. However, it stopped working after testing with other cards.

I was able to reproduce it with two other sd cards (16 GB and 64 GB). It happens after I format the sdcard using the phone. The card appears empty with two folders in Linux. Copying a folder from my home directory to the external sd card via the file browser shows the file in the external sd folder. However, browsing on the phone shows the folder in the internal storage. The same thing happens with single files.

I'm using the gnome file browser right mouse > copy and right mouse > paste functions.

I've attached a couple of log files. The .1 is with a freshly formatted sdcard. The .2 is with the original card which contains a lot of files. It displayed as containing only two folders (Android and LOST.DIR) in the gnome file browser when this log file was generated.

I also get an error message when I attempt to create and rename a folder.

Comment 4 Joshua Weage 2015-07-15 01:53:10 UTC
Created attachment 1052144 [details]
gvfsd log #1

Comment 5 Joshua Weage 2015-07-15 01:53:29 UTC
Created attachment 1052145 [details]
gvfsd log #2

Comment 6 Joshua Weage 2015-07-15 01:53:58 UTC
Created attachment 1052146 [details]
"empty" sdcard and folder rename error

Comment 7 Joshua Weage 2015-07-15 01:55:09 UTC
Created attachment 1052147 [details]
"empty" sdcard and folder rename error

Comment 8 Joshua Weage 2015-07-15 01:56:36 UTC
Created attachment 1052148 [details]
"empty" sdcard and folder rename error

Comment 9 Joshua Weage 2015-07-15 02:09:00 UTC
Any way to delete attachment #1052147 [details]? I managed to pick the wrong file.

Comment 10 Ondrej Holy 2015-07-15 06:42:08 UTC
(In reply to Joshua Weage from comment #9)
> Any way to delete attachment #1052147 [details]? I managed to pick the wrong
> file.

I'm afraid not, but I've changed it to private to reduce the risk of misuse...

Comment 11 Ondrej Holy 2015-07-15 08:55:35 UTC
Thanks for the logs. It seems you are using some older version of mtp backend then I expected.

What is your gvfs version? You mentioned 1.6.4-8.el7.x86_64 in your report, but 1.6.4 is more then 5 years old version without mtp support. Don't you think 1.16.4-8?

What version of Red Hat Enterprise Linux are you using? You selected 7.3, but neither 7.2 is not released yet. GVfs is rebased for 7.2 (Bug 1174716) and I suppose the bug is already fixed there...

Comment 12 Joshua Weage 2015-07-15 22:33:58 UTC
Thanks for hiding the attachment.

Yes, I filled in the wrong version number. I'm running CentOS 7.1:

[jweage@sailfish ~]$ uname -a
Linux sailfish.localdomain 3.10.0-229.7.2.el7.x86_64 #1 SMP Tue Jun 23 22:06:11 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[jweage@sailfish ~]$ cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core) 
[jweage@sailfish ~]$ rpm -qa | grep mtp
gvfs-mtp-1.16.4-8.el7.x86_64
libmtp-1.1.6-3.el7.x86_64

Comment 13 Ondrej Holy 2015-07-21 13:29:41 UTC
Everything looks correct from the logs. It might be something like:
https://bugzilla.gnome.org/show_bug.cgi?id=733465

I'm convinced it should be fixed in the rebased gvfs-1.22.4 package (Bug 1174716), because there were several file name related patches since 1.16.4. Can you verify that it is working correctly with 1.22.4 please? You can use Fedora 21 live cd, which contains same gvfs version...

Comment 14 Ondrej Holy 2015-07-21 14:09:28 UTC
(In reply to Ondrej Holy from comment #13)
> Everything looks correct from the logs. It might be something like:
> https://bugzilla.gnome.org/show_bug.cgi?id=733465

It would be useful to provide also output from mtp-detect (under root with connected device) to see what storage devices are reported from the device...

Comment 15 Joshua Weage 2015-08-11 01:03:35 UTC
It seems to work fine using Fedora 22.

mtp-detect appears to get stuck. It doesn't complete after the 1st attempt.

[jweage@sailfish ~]$ sudo mtp-detect
libmtp version: 1.1.6

Listing raw device(s)
Device 0 (VID=1004 and PID=631c) is a LG Electronics Inc. LG-E610/E612/E617G/E970/P700.
   Found 1 device(s):
   LG Electronics Inc.: LG-E610/E612/E617G/E970/P700 (1004:631c) @ bus 3, dev 6
Attempting to connect device(s)
libusb_detach_kernel_driver() failed, continuing anyway...: Success
ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
inep: usb_get_endpoint_status(): Device or resource busy
outep: usb_get_endpoint_status(): Device or resource busy
usb_clear_halt() on IN endpoint: Device or resource busy
usb_clear_halt() on OUT endpoint: Device or resource busy
usb_clear_halt() on INTERRUPT endpoint: Device or resource busy
libusb_detach_kernel_driver() failed, continuing anyway...: Device or resource busy
ignoring libusb_claim_interface() = -6LIBMTP PANIC: failed to open session on second attempt
Unable to open raw device 0
OK.
[jweage@sailfish ~]$ sudo mtp-detect
libmtp version: 1.1.6

Listing raw device(s)
Device 0 (VID=1004 and PID=631c) is a LG Electronics Inc. LG-E610/E612/E617G/E970/P700.
   Found 1 device(s):
   LG Electronics Inc.: LG-E610/E612/E617G/E970/P700 (1004:631c) @ bus 3, dev 6
Attempting to connect device(s)
libusb_detach_kernel_driver() failed, continuing anyway...: Success
ignoring libusb_claim_interface() = -6PTP_ERROR_IO: failed to open session, trying again after resetting USB interface
LIBMTP libusb: Attempt to reset device
Android device detected, assigning default bug flags

Comment 16 Ondrej Holy 2015-08-11 07:22:26 UTC
(In reply to Joshua Weage from comment #15)
> It seems to work fine using Fedora 22.

Thanks for testing it, so it means that the problem should be fixed also in the RHEL 7.2, because nothing important were changed in mtp backends in Fedora 22 in comparison to Fedora 21.

> mtp-detect appears to get stuck. It doesn't complete after the 1st attempt.

You have to be sure that nothing else is using mtp. Try to unmount the gvfs mount before. However it isn't necessary if it works in Fedora 22.

Comment 19 Matěj Cepl 2015-09-16 18:53:42 UTC
On Sony Erricson Xperia M2 (USB ID: 0fce:51aa, covered in the upstream music-players.h, but not yet in the one in RHEL 7.2) I can copy file to SD Card and I can then find it with Android's File Commander truly to be on the SD Card.

libmtp-1.1.6-3.el7.x86_64
gvfs-mtp-1.22.4-4.el7.x86_64

Comment 21 errata-xmlrpc 2015-11-19 09:29:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2106.html


Note You need to log in before you can comment on or make changes to this bug.