Nemo: File transfer hangs at 99.9% and 100%

[AXDOOMER]

This is a new problem that I have in Linux Mint 17.2 (kernel: 3.19.0-21-generic). I never had this problem before because older versions didn't have the sequential file transfer tool, so I suspect this is the cause of the problem. I often copy files from any sizes and it does this. It hangs and I have to wait from 5 to 10 minutes. I am transferring from my SSD (~/Download) to my USB Flash Drive (CANADA).

In the case where this would be a kernel related bug, could the file transfer tool be updated so it could take the "hanging" factor into account when it transfers file? (so for example, it would tell the user that the file transfer tool is waiting for the drive to complete its operation)

It is a serious issue when the files transfer tools tells there's "0 seconds" left to the transfer and then the user has to wait 10 minutes. Also, when there is 1 or 0 second left, it should be written "# second" instead of "# seconds" (plural form).

[Vahan86]

@AXDOOMER, is this still an issue for you in Nemo 3.0.6 (Mint 18)?

[AXDOOMER]

I'm not running Mint anymore, but I'm sure this is still an issue. If you want to know if it's fixed, find the commit that patches this bug. As far as I know, no one worked on this bug to fix it.

There is a reason why it happens. The file is copied into a buffer. When the file is completely in the buffer, it displays 99.9%, but it's still being written to the USD flash drive which is slow. If the buffer and the file are huge, then it stays at 99,9% for a long time.

[cesc1989]

This is still a thing in Linux Mint 19.1

[leandrorebelo]

This bug happens in Linux Mint 19.1 :(

[UriNeri]

@AXDOOMER
Did you find a distro without this bug ?
(Still exist in Linux Mint 19)

[AXDOOMER]

@UriNeri As far as I know, this bug also happens on Xubuntu. I didn't notice it on other distros, which doesn't mean it doesn't exist elsewhere.

I have 16GB of RAM in my computer and if I copy a 4GB file to a slow USB flash drive, it copies at more than 100MB/s for the first 2GB, then it decreases to ~1MB/s for the remaining. When it reaches 99%, it hangs.

There must be a way for the distro to be tuned so it uses a smaller buffer, especially when copying to slow devices. Another possibility would be to find out the amount of data that was written to the disk, in order to get the real amount of data copied.

The best explanation for this bug is what I have read here: https://unix.stackexchange.com/a/181236

[UriNeri]

@AXDOOMER
Thanks. I switched to Xubuntu and the Issue doesn't reoccur (or rather, I haven't encountered it yet). Overall, while missing some fancy features, Thunar is less buggy than nemo. No disrespect for the Devs, of course, who do wonderful work.

For the issue though, a dynamic control on buffer size would be optimal, and it would be independent of distro (as your link suggest, the cause is could be at the kernel level).

[shyaminayesh]

Issue is still here. Running nemo v4.4.2 on Arch linux with Kernel 5.5.9 & file copy process hang on 98%-100% when copyig to external drive.

[arievanden]

I've been experiencing the exact same issue, but with latest Manjaro KDE install. I'm loving it, except for the file copy lag issues. I first through it was a problem with copying to Samba share, but I tested a copy to USB thumb drive and the slowdown is exactly the same. When copying a large file like 4gig file, it starts to slow down around 50% of the way, then takes a steep drive in write speed until it hangs. If you let it be for a while, it will sometimes finish. But it hangs for a long time at 99%, then usually completes. File utilities like Dolphin will hang/lag until the copy is complete.

[yuuki-san]

Still present in Manjaro 20.1 (Linux kernel 5.8.6-1) and Nemo 4.6.5-1.
Tried to copy a file from one external drive (USB-C) to another (USB 3.0) - took about 2 minutes to copy it but another 5 minutes to actually go from 99% to 100% and finishing off.

[Jeremy7701]

When you output to a device from memory, you have no way of knowing how many bytes have completed their journey from memory buffer to final storage successfully. Even when nothing is apparently happening, the USB is still running at full speed.
USB is notoriously slow when writing - perhaps half the read speed of the same USB.
An average PC can easily buffer several GBytes of data.
A "fix" could involve writing a small portion, waiting for it to complete before dribbling another small portion and so forth.
You could tell the kernel to use smaller amounts of buffer space for all processes....
This would be wastefully slow.
One solution would be to get a smaller computer.

[AXDOOMER]

Instead of buffering Gigabytes of data, the buffer could instead be, let's say, 256 Megabytes. This way it's not slow and wasteful, but it reduces the time you have to wait for your file to complete when it's at 99% completion.

[Jeremy7701]

Well, you could use spare memory as at present, but if you discover you are writing to a USB device you could issue the equivalent of a sync command (see man page) every 256MB to force completion of any outstanding output.
This will reduce the already slow output performance of USB - quite possibly substantially.
But it would allow your progress bar to be more active.
Might be worth trying a loop in a script using split and sync to see how well a big file split into 256MB chunks can be written (with a sync after each chunk is written).

[dipenSan]

I still face this problem in Mint 20 Cinnamon.