Serious (data loss) bug when destination becomes unavailable

[dhay]

During a move operation from a local (same bug with remote) folder to another shared remote folder on another PC, if that remote PC crashes or is stopped, TC *deletes all the selected local files* that were supposed to be moved !!!!

Can't it simply abort the copy process and NOT delete the files? I just lost a bunch of precious photos like this.

100% repeatable. Start a move operation and shutdown the remote computer...

In my book, this is an extremely serious bug.

[ghisler(Author)]

Sorry, cannot reproduce. Can you give me more details, e.g. what copy method you use, what TC version and Windows? Total Commander only deletes files when it receives the confirmation from the system that the copy operation was successful.

[dhay]

Hi,

In my case, I get this when copying from a local WinXP SP3 using the default (the "standard") copy method to a Windows 7 x64 shared directory.

I wanted to move several large files from the XP PC to the Win 7 one, and unfortunately, the Windows 7 PC crashed at that time. As I was also watching videos streaming from this Win7 PC at that time, I noticed the crash immediately and pressed PAUSE on the move process, thinking that things would resume afterwards.... and unfortunately, it simply deleted all the selected files for the move operation from the local PC when resuming.

Since then, I tried again on non-important files, and any kind of connection loss between the two computers always produces this problem.

[ghisler(Author)]

Thanks for the details, I will try to reproduce it with your settings:
1. Source us XP SP3
2. Target is Windows 7 x64
3. Windows 7 crashes (e.g. is turned off) with no chance to tell the peers about the shutdown
4. You are moving in the background with standard (CopyFileEx) function

[ghisler(Author)]

According to my tests, the problem is caused by the Windows 7 disk cache (write cache). Here are the results of my tests (I tested everything twice, once in the foreground, once with the background transfer manager):

1. While moving files, I have unplugged the network cable of the target system (so the source didn't know about it)
-> The currently moved file arrived only partially on the target, but the source was not deleted. The move operation stopped immediately, and showed an error message after a few seconds.

2. Same scenario, but I chose "Shutdown" on the target system while moving the files -> Same result as with 1, no data was lost.

3. Same scenario, but I pressed the reset key on the target system during the move operation. Result: The moved files were all there (the names), but they were all empty. Apparently Windows managed to create the files, but the write cache didn't have the time yet to write the data to them.

I guess that you must have seen a scenario like Nr. 3, where Windows 7 crashed so badly that it couldn't even write its write cache to disk.

I have never seen Windows 7 crashing, so you should first try to fix that problem. While it is so unstable, I recommend that you copy files over the network and delete the originals only later. Unfortunately there is no way to check the state of the write cache on Windows, or even tell Windows to flush the cache.

[wanderer]

Unfortunately there is no way to check the state of the write cache on Windows, or even tell Windows to flush the cache.

Hi everyone.

Indeed there is no (known/documented) way to tell the destination computer to "flush its cache" after a copy operation. One can manually run Windows SysInternals Sync utility in the destination computer though after a copy operation has been completed to make sure the cache is flushed before deleting the files from the source computer.