15
exerceo
2y

MTP is utter garbage and belongs to the technological hall of shame.

MTP (media transfer protocol, or, more accurately, MOST TERRIBLE PROTOCOL) sometimes spontaneously stops responding, causing Windows Explorer to show its green placebo progress bar inside the file path bar which never reaches the end, and sometimes to whiningly show "(not responding)" with that white layer of mist fading in. Sometimes lists files' dates as 1970-01-01 (which is the Unix epoch), sometimes shows former names of folders prior to being renamed, even after refreshing. I refer to them as "ghost folders". As well known, large directories load extremely slowly in MTP. A directory listing with one thousand files could take well over a minute to load. On mass storage and FTP? Three seconds at most. Sometimes, new files are not even listed until rebooting the smartphone!

Arguably, MTP "has" no bugs. It IS a bug. There is so much more wrong with it that it does not even fit into one post. Therefore it has to be expanded into the comments.

When moving files within an MTP device, MTP does not directly move the selected files, but creates a copy and then deletes the source file, causing both needless wear on the mobile device' flash memory and the loss of files' original date and time attribute. Sometimes, the simple act of renaming a file causes Windows Explorer to stop responding until unplugging the MTP device. It actually once unfreezed after more than half an hour where I did something else in the meantime, but come on, who likes to wait that long? Thankfully, this has not happened to me on Linux file managers such as Nemo yet.

When moving files out using MTP, Windows Explorer does not move and delete each selected file individually, but only deletes the whole selection after finishing the transfer. This means that if the process crashes, no space has been freed on the MTP device (usually a smartphone), and one will have to carefully sort out a mess of duplicates. Linux file managers thankfully delete the source files individually.

Also, for each file transferred from an MTP device onto a mass storage device, Windows has the strange behaviour of briefly creating a file on the target device with the size of the entire selection. It does not actually write that amount of data for each file, since it couldn't do so in this short time, but the current file is listed with that size in Windows Explorer. You can test this by refreshing the target directory shortly after starting a file transfer of multiple selected files originating from an MTP device. For example, when copying or moving out 01.MP4 to 10.MP4, while 01.MP4 is being written, it is listed with the file size of all 01.MP4 to 10.MP4 combined, on the target device, and the file actually exists with that size on the file system for a brief moment. The same happens with each file of the selection. This means that the target device needs almost twice the free space as the selection of files on the source MTP device to be able to accept the incoming files, since the last file, 10.MP4 in this example, temporarily has the total size of 01.MP4 to 10.MP4. This strange behaviour has been on Windows since at least Windows 7, presumably since Microsoft implemented MTP, and has still not been changed. Perhaps the goal is to reserve space on the target device? However, it reserves far too much space.

When transfering from MTP to a UDF file system, sometimes it fails to transfer ZIP files, and only copies the first few bytes. 208 or 74 bytes in my testing.

When transfering several thousand files, Windows Explorer also sometimes decides to quit and restart in midst of the transfer. Also, I sometimes move files out by loading a part of the directory listing in Windows Explorer and then hitting "Esc" because it would take too long to load the entire directory listing. It actually once assigned the wrong file names, which I noticed since file naming conflicts would occur where the source and target files with the same names would have different sizes and time stamps. Both files were intact, but the target file had the name of a different file. You'd think they would figure something like this out after two decades, but no. On Linux, the MTP directory listing is only shown after it is loaded in entirety. However, if the directory has too many files, it fails with an "libmtp: couldn't get object handles" error without listing anything.

Sometimes, a folder appears empty until refreshing one more time. Sometimes, copying a folder out causes a blank folder to be copied to the target. This is why on MTP, only a selection of files and never folders should be moved out, due to the risk of the folder being deleted without everything having been transferred completely.

(continued below)

Comments
  • 4
    Sometimes, I get a "data supplied is of wrong type". Other reports of this error:

    * https://forums.androidcentral.com/s...

    * https://bleepingcomputer.com/forums...

    Sometimes, instead of files, blank placeholders with a HDD icon with a Windows logo appear! ( https://imgur.com/a/iosQaL5 ).

    When double-clicking two folders in quick succession, it might end up showing the second folder as path but show the contents from the first folder! I hope I don't need to clarify how lunatic this is.
  • 4
    By the way, while a MTP file transfer is in progress, guess what else you can do. Nothing! That's because MTP lacks parallelism, the ability to do more than one task in background. So you would like to browse photos on your phone while files are being transferred? Bad luck! MTP can't do that! Additionally, MTP lacks random access, meaning if you want to watch that 3 GB 4K 2160p video file, tough luck. The file manager will have to copy it to your computer first so it can read the MOOV atom at the end of the file, which is necessary for playback on "program stream" video files. If your operating system runs on SSD, that's 3 GB of weardown just so you can play a video once. Technically, sequential reading could be possible without downloading the whole file, but many files require random access.

    Did I mention yet that MTP sometimes disconnects or freezes up during file transfers?
  • 4
    When trying to copy a large folder with several thousand files, Windows just indicates "calculating time to copy files" for several minutes. This apparently is intended to excuse the time it needs to get a list of paths for transfering. The Nemo file manager from Linux at least shows how many files it has counted so far. This is a huge benefit, since it lets the user know whether it is doing anything at all, or, as often happens on MTP, is frozen and not doing anything.

    It almost seems like MTP was designed with the goal to be as annoying (to avoid using an s-word) and buggy as anyhow possible. It almost seems like there was a competition to design a transfer protocol that fails as hard as imaginable.
  • 4
    Here is even a report of the entire internal storage disappearing:

    https://reddit.com/r/Android/...

    Internal storage = no data recovery software available due to lack of block-level access. I wonder how many terabytes of data MTP bugs have destroyed.

    Isn't Microsoft who designed MTP for their Zune player? Then how come their file manager has a worse and less stable implementation of it than Linux file managers such as Nemo? You'd think the creator's implementation is the most stable and functional, but no. That's especially embarrassing regarding that Microsoft is a billion-dollar corporation with paid employees whereas Linux software such as Nemo file manager is largely developed by volunteers for fun. Granted, Microsoft implemented UDF packet writing (live file system) on optical discs very well starting with Windows Vista.
  • 4
    If MTP was created by 13-year-old computer science students as a school project, it might have been somewhat respectible. But it was created by well-paid programmers from a billion-dollar corporation.

    To manage files using MTP is to walk on eggshells.

    Comparing Miserable Transfer Protocol to mass storage and FTP is like comparing a chinese scrapyard car to a German luxury vehicle. On mass storage and FTP, files' date and time stamps are always listed correctly and retained when transfering either way, files are actually moved within the device instead of copy-deleted, large directories with thousands of files load within few seconds compared to minutes on MTP (if it even reaches the end without hanging up in midst of the process); and mass storage allows keeping the date and time attribute when adding files.
  • 4
    Funnily enough, Windows Explorer's integrated FTP implementation sometimes only reads the date and not the time of files, but FileZilla solves this problem anyway and retaining the date and time attribute can be enabled in FileZilla using CTRL+U. It should have been enabled by default, but that's a different topic.

    I now realize what luxury we had in 2009, back when mass storage was an option for smartphone file transfer, before it was locked away by our "benevolent" smartphone and operating system vendors.

    I imagine MTP is the only allowed method of transferring files in hell.

    https://youtube.com/watch/...

    MTP is one of the darkest stains in the history of computer file management. It belongs to the same place in history as the Galaxy Note 7 and the Fiat Multipla.
  • 10
    And the award for Most Triggered Programmer goes to...
  • 2
    Are you mad?
  • 3
    I bet you this screenshot won't even be readable with devRant compression
  • 2
  • 2
    @ScriptCoded how did you get your os to capture the whole page instead of just the current viewport ?
  • 2
    Half of those are just Windows Explorer features, but that doesn't erase MTP's bad performance and reliability. It's so bad that you should use wlan instead.
  • 2
    @AvatarOfKaine some phones have that feature, it keeps making a screenshot as you scroll down
  • 6
    11/10 proper rant! Fuck MTP
  • 0
    Just wait until they tie your social media score with your features on your devices. The AI will see you hate MTP and disable it on your devices.
  • 3
    Yeah, FUCK MTP HARD!

    Worst protocol ever.

    Apparently it is the only *functional* protocol that is able to mount device memory without unmounting it first. What would happen apparently when you mounted your phone as Mass storage device (which worked perfectly for me) it would have to unmount from the phone and mount it to you, which could cause some apps to corrupt themselves. Apparently MTP was created to essentially work around that situation. So it's moving around data safely while the card/memory is being mounted within the phone.

    I'd have *some* understanding towards the weird behavior considering it's trying to navigate around data that is also constantly being used and read. But that would only apply if MTP worked at all for me!... I wasn't able to get an MTP to rename, let alone transfer or move data for at least half a decade now. I just use network solutions instead. Mainly KDE Connect and it's Browser and "Send to Device" operations...

    fuck mtp
  • 1
    @AvatarOfKaine I seriously considered not answering you, but I heard something about being the bigger man 🙄 it asks me when I take a screenshot
  • 3
    Gonna be honest with you....
  • 4
  • 0
    @ScriptCoded oh yes remember that phone littler man
  • 0
  • 0
    @ScriptCoded wanna cuddle I'm cold? It's aj opportunity for it to be a consensual thing and I'm the one who said that originally lol
  • 0
    Jesus the deja Vu is piling up
  • 2
    @Demolishun Haha I love how you completely misunderstood the situation 😁

    https://devrant.com/rants/6167177/...
  • 2
    @ScriptCoded 🍿
    I'm still baffled about how this can keep continuing.
  • 0
    @electrineer I'm still wondering why mtp has created so much hate
  • 1
    @ScriptCoded Ahh, dont feed the natives.
  • 2
  • 2
    @ScriptCoded lol, did I just say the most racist thing ever? not the intent.
Add Comment