deleting mtp files > report a bug

[mustafaabdd5]

so i have been using free file sync for a while .. i am syncing folder between a laptop and android phone(mtp folder)
i put the comparison setting on file size and synchronization on mirror and things go just fine

the problem occur when there is a file to delete in mtp folder the program completely stop and i have to disconnect the phone to restore things >>> :(
so i tried to delete them manually from the program .. but it always stops while deleting second file
yes first file deleted just fine >>> second file boom all things stop ..
sound weird you can try it yourself to be sure

Now i deal with this problem by right click on files then click "show in explorer" and deleting them manually from windows explorer

hope the team can fix this bug
sorry for my English and thanks :)

[Zenju]

Seems related: viewtopic.php?t=4589
Unfortunately I'm not able to reproduce this behavior, which I suspect to be a device-specific MTP issue rather than caused by FFS.

[mustafaabdd5]

Seems related: viewtopic.php?t=4589
Unfortunately I'm not able to reproduce this behavior, which I suspect to be a device-specific MTP issue rather than caused by FFS.

thanks for replying

which phone work in your trial ?
for me the issue occurred on 3 phones samsung S7 edge , samsung note 3, and huawei gra-ul10

by the way i am using windows version of FFS , could it be the cause ?

[Zenju]

It's a HTC Desire 310 on Android 4.2.2 (Jelly Bean)

[blutroniq]

It's a HTC Desire 310 on Android 4.2.2 (Jelly Bean)

I have the same issue both with a Nexus 6P and a Samsung Galaxy S8+. Perhaps newer phones treat files somewhat differently? The model you are testing with is 4 years old.

[terrapin]

This actually occurs whenever FFS tries to delete multiple files over MTP. I have this problem with both a Pixel 2 (Android Pie) and a Galaxy Tab A (Android Oreo).

If you leave FFS alone (i.e. frozen) for long enough something eventually clicks and the sync then continues. When syncing with the Tab A this takes about 7 minutes of FFS freezing with no activity, it's 2 to 4 minutes with the Pixel 2. Has been identified as an issue for over a year now, would truly love for this bug to be fixed.

[Zenju]

I'm pretty sure this is a driver bug since FFS exactly adheres to the official API. But you never know: It's a long shot, maybe a slight change in how the MTP deletion API is called does something:
https://www.mediafire.com/file/lxhlwbhwqn5ww1i/FreeFileSync_10.6_%5BBeta%5D_Windows_Setup.exe/file

[terrapin]

Thank you for the 10.6 beta Zenju - I've tried it out but unfortunately the problem is still there, it may even be slightly worse. The time taken for the issue to clear with my Samsung Galaxy Tab A is now close to 10 minutes of the sync being frozen when trying to delete the second file. A screenshot of the sync timeline graph is attached.

TabASync181026.jpg (127.84 KiB) Viewed 4605 times

[terrapin]

The exact same sync with my Pixel 2 only freezes for about 30 seconds. You can see below that a few operations happen at the beginning, but when it gets to deleting the second file it freezes until something gives about 30 seconds later (or 10 minutes later with my Tab A).

Pixel2Sync181026.jpg (121.45 KiB) Viewed 4605 times

[Zenju]

It seems the hangs are caused by software running on Android (media library or the like) that is not expecting certain files (images or videos) to suddenly disappear.

In this discussion it is suggested that putting a ".nomedia" file into the respective folders avoids media files to be indexed by the buggy (or let's say "not MTP-aware") software on Android, thous no more hangs when the media files are deleted:
https://productforums.google.com/forum/#!topic/nexus/_CgDd5ZJ2qw/discussion

[terrapin]

Have tried a couple of ways of adding a ".nomedia" file, both through Windows and on the devices themselves, but no luck so far in even creating the file. If a number of manual steps have to be done (and presumably undone to remove the files after the sync) then it rather defeats the purpose of having an automatic sync. Have resigned myself to waiting 8 minutes for the sync to unfreeze itself rather than fiddling about adding and removing ".nomedia" files. That also assumes that it would actually fix the issue... happy to beta test if there are things that can be improved with respect to the implementation of the MTP protocol.

[terrapin]

Just in case it makes a difference, the files being synced on my Pixel 2 are stored on the inbuilt storage, whereas the files on my Tab A are stored on a MicroSD card.

[rogw]

Hi. I am also seeing deletion of multiple files taking forever (after the first file deletion succeeds) in MTP directories (Samsung J5 Prime phone). Not quite a hang, but the "Synchronising..." window persists for a long time (tens of minutes) with the time graphs continuing to run, and no further deletions occurring, as others have observed above.

I have put ".nomedia" files in all target directories and rebooted the phone, but the problem persists. Target directories are on a microSD card in the phone. No problem deleting these files locally on the phone. FFS 10.8 running on Windows 8.1.

Any further clues?
Otherwise FFS is excellent. Thanks.

[tharg]

Over a year later, I get the same problem on a Galaxy Tab-E from Windows 10. FreeFileSync_10.13_Windows_Setup.exe
FFS is too unreliable for an overnight scheduled task for Android devices.
Between windows machines it's fine, once the sharing and protection is sorted.
Would have donated by now if this bug was fixed.

[tharg]

Seems like it's not a problem with FFS, but with Android. From windows explorer, if I attempt to move a folder from one place to another I see a similar problem. It fails.

[xCSxXenon]

This has been an ongoing issue with MTP. It is a horrible protocol when dealing with deleting and manipulating files on Android devices. It has gotten better as phones have gotten better hardware to deal with the processes it goes through, but still can have issues. It is really only an issue when dealing with a lot of I/O operations in a short time, which since deleting files is fast, it tends to overload whatever link in the chain.

[tharg]

One option would be to change the failing remote rename to a delete-first-then-copy. I use SymbSync2 for Android. It has this option and it works fine. Could this be added to freeFileSync as an option?

[xCSxXenon]

That would not extend the idle time between interactions considerably enough to change anything. That would be stuffing two handshakes in .5 seconds rather than one in .1 seconds, example numbers.

[tharg]

Have you tried it?

[Zenju]

One option would be to change the failing remote rename to a delete-first-then-copy. I use SymbSync2 for Android. It has this option and it works fine. Could this be added to freeFileSync as an option?

You can disable fail-safe file copy to test this with FreeFileSync.