Menu

#1830 Hang/freeze with filename length = 22 characters (including .jpg or .png extension)

1.1.14
closed
None
1
2020-02-27
2019-02-18
angus73
No

I found this strange behaviour when I tried to access, through Nautilus, a folder mounted with mtp from my Samsung Android Device: if the folder contains an image file named 20180915_180351(0).jpg, Nautilus hangs, freezes, doesn't respond, and I have to unplug the phone to have it back working.

This is particularly annoying because Android sometimes creates files with name YYYYMMDD_HHMMSS(n).jpg, with n=0, 1, 2, ... when more than one photo are taken in the same 1-second time interval.

I think it is a libmtp problem and not strictly nautilus-related, because the same problem triggers if I try to browse the directory using the command line on the device storage mounted with jmtpfs.

Some trials pointed out that the problem happens with image files having a filename length of exactly 22 characters (i.e. "123456789012345678.jpg"), and a jpg or png file extension. I have not been able to reproduce the bug in other circumstances (despite I tried many). Here is the log of my tests:

Does it depend on the "(" or ")" characters?
20180915_183051(0).jpg DOES NOT WORK
Same image renamed to:
20180915_183051(x).jpg doesn't work
20180915_183051(0.jpg works
20180915_1830510).jpg works
20180915_183051(00).jpg works

20180915_183051().jpg works
...so, the answer is NO.

Does it depend on the filename length?
20180915_183051(0).jpg DOES NOT WORK
Same image renamed to:
Test(0).jpg works.
1234567890(0).jpg works.
12345678901234567890(0).jpg works
12345678_012345(0).jpg DOES NOT WORK
123456789012345(0).jpg DOES NOT WORK
1234567890123456(0).jpg WORKS
12345678901234(0).jpg WORKS
123456789012345678.jpg DOES NOT WORK
1234567890123456789012 works

123456789012345678.012 works
...so it seems the answer is YES, but the last two's suggested me also to try:

Does it depend on the extension itself? (not the file content type)
123456789012345678.txt (text file) works
The above file renamed to .jpg does not work;
123456789012345678.png (image file) does not work;
The above file renamed to .txt works;
The above file renamed to .jpg does not work.
...so, it seems it does.

Other thoughts:

Does it depend on file size? Does not seem so:
2.0 MB works
2.4 MB doesn't work
5.0 MB works

Steps to reproduce:
- On the mobile device, create a folder "test" and copy an image file "123456789012345678.jpg" inside it;
- Connect the mobile device, allow access to phone data;
- On the PC, open Nautilus and navigate to the "test" folder

Expected behaviour:
The file is shown

Real behaviour:
The file is not shown; Nautilus hangs/freezes until the device is unplugged. Sometimes an error pops up "libmtp error: unknown error / unmanaged error"; sometimes "could not get object handles".

Running libmtp libmtp-1.1.14 on Fedora 28 with a Samsung J7.

Of course, let me know if I may provide more info or test results.

Discussion

  • Marcus Meissner

    Marcus Meissner - 2019-02-20

    can you run try it with our commandline tools and capture debug, so something similra to:

    LIBMTP_DEBUG=255 mtp-files >debug.logfile 2>&1

     
  • angus73

    angus73 - 2019-02-21

    There is also a thread about this on the list, starting here:

    https://sourceforge.net/p/libmtp/mailman/message/36592263/

     
    • angus73

      angus73 - 2019-03-03

      ...and the discussion lead to think this is related to bug #1808

       
  • Marcus Meissner

    Marcus Meissner - 2019-03-03
    • status: open --> pending
    • assigned_to: Marcus Meissner
     
  • Mne

    Mne - 2020-02-26

    I was, too, affected by this issue (reproduced with libmtp 1.1.16) but it looks like the current version, 1.1.17 (master git f5ea96b1879dba9952c1c3ad12ada5aff1334352 commit actually), works poperly.

     
  • Marcus Meissner

    Marcus Meissner - 2020-02-27
    • status: pending --> closed
     
  • Marcus Meissner

    Marcus Meissner - 2020-02-27

    thanks for testing!

    The likely fix was:

    commit 4df11dcf5efa4b4eb626a988c5557c1a04a5c6db
    Author: Marcus Meissner marcus@jet.franken.de
    Date: Sun Oct 28 09:21:16 2018 +0100

    replace 64bit hardcoded packetsize by inep maxpacketsize
    
     
  • Air

    Air - 2020-02-27

    Thank you, as well, for the amaizing job!

     

Anonymous
Anonymous

Add attachments
Cancel