Error when copying to external device

[kekz]

Hi!

I have a problem when copying/moving files to my external hard drives.

Scenario:
I copy/move a file from my hard drive to an external device. The progress bar runs smoothly until 99% and then displays the following error (additionally I attached a screenshot):

Code: [Select]

---------------------------
Error
---------------------------
Error occurred while trying to write data in a optimized way.
Some part(s) of your hardware might not support that.

Try to Disable "Automatically detect read/write stratergy" in Core settings
---------------------------
Retry   Skip   Abort   
---------------------------

If I disable "Automatically detect read/write stratergy" the error does NOT occur, BUT then the copy progress is kind of broken.
The progress is much too fast and then hangs at the end. This also affects devices that are unaffected by the original error.

I already saw the broken copy progress bar behavior in my previously used commander (commercial SpeedCommander) and was happy that I had a nice progress prediction again, one like the new windows versions have too.

Is there some way to fix this behavior in a way that I get a smooth and successful file copy experience?

Additional information:
- Core Settings>FileSystem is on default values regarding the other values
- the file shows up in the destination folder, but a few hundred kb are missing, so there is indeed something going wrong
- original file size doesn't seem to matter, kb/mb/gb
- error does not occur when copying FROM the external devices
- happens on both my external hard drives: Seagate Expansion Desk, 4 TB, USB3; Western Digital External HDD 1021, 3 TB, USB2
- does not happen on my 2.5" external drive or USB flash drives, but they were all <1 TB
- all tested devices use NTFS

[Mathias (Author)]

The broken progress come from the fact that when that option is enabled, the data will go through the Windows File system cache. (And drive cache)
and the progress is done when the data has been sent to the cache. not when the data is actually written.  MC do not have any control of that, Windows decides when it want to write it.  (No program does, all have this issue.) However when a files is copied, MC tells windows to Windows to make sure that the file is written.
So thats why it can stall for a bit at 100%, Because it will wait until Windows say "There, now the file is written and safe, Now you can continue"

However MC by default is trying to use optimized read/write and that is too NOT use the FileSystem filecache on write.
Because that will as you see give false sense of when the data is written, but is often also slower because data is copied into the cache first, And when cache is full
everything stall. and if the file is very very large you will see progress go fast a bit then stop, and then go fast for a bit and then stop.

By telling windows to bypass the file system cache and/or drive cache there are a lot more restrictions, And all hardware involved must support this.
The drive, The USB HD controller, chipset and so on All hardware part involved. Often today this is not a problem. But it happens that some HW does not support it.
Most often you get 0 byte file and it fails directly. That is fails at the end is a little more uncommon. There might be more info in the file operation log when this happen (Ctrl+L)

In the "Copy To" dialog if you expand it fully, you see what Read/Write strategy is being used. If you disabled the settings (automatic..bla bla.), it will always pick "Normal ..." But else it should pick "To External Device (USB/Firewire)" when you copy from local to USB device, and you can click "..." and you can tweak all the settings that Windows allows to be played with. It is not much. "Use System cache" should already be "uncheck" for write. You can try to uncheck "use drive cache" but I'm not sure that will help.

That it fails at the end indicate that the last "block" that is written, fails. And that can happen for a couple of different reasons. It might say more about that in the file operations log.

[kekz]

Thanks for your extensive explanation. I understand that this issue affects all programs.
I played around with the options. Sadly, deactivating "use drive cache" didnt help
But at least I can control the behavior more fine grained by activating system cache for the external drive profile, than completly disabling the automatic strategy, thx!

[My711thLoginHandle]

I too have this issue, even after the update of the program today. I disabled that option to "auto detect" but copying to my external still fails. Seems to even not copy when I do CTRL-C. I have to drag/drop being careful not to move (I hate moving files and it fails).
What else can I try?

[Mathias (Author)]

Ctrl+C do not copy.. it only prepare file to be copied so it can be copied on Ctrl+V, But it is windows that handles that,
Try to use the built in copy process in MC ,  (F4/F5 depending on keysetup or Copy button on button panel , Toolbar or menu>File)
And if something fails check the log (Ctrl+L) and see if there are any information on why it failed

[My711thLoginHandle]

Yes, CTRL-V pastes it, that would have been a given when I mentioned CTRL-C.

I will try your other methods, but the issue still stands that the process fails for the same errors above.

Here are the errors:

2016-02-14 17:50:34.483 Unable to open target file : Z:\ABCD.avi ( Error code : 10, Internal Error Code : 80)
2016-02-14 17:50:34.484 File Operations error : 10 (80) -
2016-02-14 17:53:38.786 Write data failed (WinError 87) (239616 , 0, 512)
2016-02-14 17:53:38.788 [7892] WriteThread - Failed to write to file (Error code : 173, Internal Error Code : 87 - DBG 0x000002DE5C1A0000 , 239616 , 0)
2016-02-14 17:53:38.806 File Operations error : 173 (87) -
2016-02-14 17:54:12.426 [7892] WriteThread : User requested abort of operation
2016-02-14 17:54:12.527 [7776] WaitForState : wait for 6 , current state is 6
2016-02-14 17:54:12.527 Copied : "C:\ABCD.avi" => "Z:\ABCD.avi" - 734265344 bytes (700.

[Mathias (Author)]

That error is because the device does not support optimized write.
You said you disabled "auto detect", But some how it tried to use it anyway.. Maybe you modified the read/write parameters for the "normal" read/write strategy