Problem in copying files: TC does not warn that "the file is no longer available"

[retalv]

I'm sorry to bother you again, this time the problem is about the copy function.

The presence in the application of various methodologies makes me aware that copying problems are not new and that there are many devices and systems, but the behavior I will describe is strange ...

TC9.50 x64 beta5 in a practically standard configuration (but the same thing using TC9.22a stable) freezes while copying a file folder (F5) with the verification request (which obviously fails to execute) of a file set backup (Macrium Reflect, alias .mrimg) large (approximately 223GB) from an external USB3 unit to standard internal SATA disk or SSD.

The block is only at the application level and the only key that responds without obtaining any result is the [PAUSE / START] key: the [Cancel] and [In the background] keys do not show signs of life and therefore leave the Application remains no other way than to terminate the TC process.

The freezing of the application is random and occurs between 05% and 90% of the copy, in other words it does not happen in a well defined point of the copying operation, but it is repeated anyway at every attempt.

Both source-destination disks do not present any filesystem (NTFS) errors.

The same operation attempted with TC9.22a (with standard copying method) DOES NOT reach the end of the copy, also in this case due to freezing of the schell.

Using copy / paste of the system with "Explorer" on the single file of 223 GB (239.984.029.696 byte) or in TC the copy method with verification for large files in conjunction with the compatible method for USB memories always on single file (or even the standard copy method of TC), the copying process proceeds and ends without problems.

Instead, using the same copy method with TC with verification for large files in conjunction with the USB memory compatible method, BUT by copying the source folder named [FINALE] with path [e:\BACKUP_LinuxMint_W10Home_B1909\FINALE] containing the previously described large file "5CC6872F737DAE92-00-00.mrimg" plus a small 1K ANSI file "Descrizione.txt", the copy process freezes ...

For obvious reasons (including the size) I would not send you the file, but considering that its content does not seem to be the problem, I believe that by creating the folder and the files with the given names you can reproduce the anomaly, perhaps briefly describing the reason.

I tried to be as clear as possible, if it were not probably the fault of Google Translator ... however I am always available. Mail in my profile is active...

Machine: ASUS with Windows7 Professional x64 - Intel I5 - 16GB of RAM, operating system updated in November 2019.

[ghisler(Author)]

TC uses standard Windows function CopyFileEx (Unicode version) for copying files in the standard configuration. I'm not aware of any bugs in it which could cause a freeze. Maybe you didn't wait long enough?

[retalv]

If I wait 30-40 minutes without seeing the progress bar progress, no change in the copy speed indicator, no flash activity of the disk activity and 0 disk resources do you think the wait can be enough ..?

[Usher]

Machine: ASUS with Windows7 Professional x64 - Intel I5 - 16GB of RAM, operating system updated in November 2019.

Your machine is old enough to replace Power Supply Unit, I think.

[retalv]

Your machine is old enough to replace Power Supply Unit, I think.

No, the problem is not the old machine nor the power supply (if it works well why change it?), everything works like a Swiss watch: if it was a machine problem the whole system would have crashed.
Unfortunately the problem is the USB3 HD drive, and TC that doesn't notice the problem ...

[retalv]

TC uses standard Windows function CopyFileEx (Unicode version) for copying files in the standard configuration. I'm not aware of any bugs in it which could cause a freeze. Maybe you didn't wait long enough?

As I said to the other user, I understood what is the problem.

The USB3 HD drive is (for some reason) improperly disconnected randomly from the system and this generates the stall during copying.

It happened to me while I was copying the folder by copy-paste using the "Explorer" function of the system.

The problem is that while in this case you are warned of improper disconnection (the message roughly says "the file is no longer available") TC does not warn of the error and continues undaunted to try to copy a source that has become non-existent.

At this point I apologize and ask that the errors that could be generated in the copying phase are displayed, so as to prevent the application from stalling.

Greetings.

[Usher]

Unfortunately the problem is the USB3 HD drive, and TC that doesn't notice the problem ...

Have you changed power saving options for USB ports?

[retalv]

Have you changed power saving options for USB ports?

No, no change in the power saving options and more generally no change to the standard settings of the USB ports. The USB3 drive (see first post) is self-powered and I've never had problems like this before.

I will further investigate the causes, not least the USB interface of the drive.

[Dalai]

Well, usually TC tells you when an error occurs during a file transfer. When this doesn't happen in your case, it might be that the system doesn't report errors properly to the application(s).

Regards
Dalai

[retalv]

Well, usually TC tells you when an error occurs during a file transfer. When this doesn't happen in your case, it might be that the system doesn't report errors properly to the application(s).

I understand, but if the cable is disconnected it is the system that must realize that there is a problem and at least go to timeout: even physically disconnecting the TC cable continues to wait for infinity data from a device that is not physically and logically present.

In any case, TC must respond at least in the same way as Explorer, saying that the file is no longer present, not just waiting endlessly. This is in any case a TC bug.

Probably even the interface on the drive side is not exactly the best or even for this failure to report the problem is only the connection cable ...

However, after further analysis I think I have limited the problem by tracing it back to the low quality USB3 - USB Micro B cable: changing the cable the problem of disconnections has not been repeated and it seems that the copy proceeds without a hitch.

Sorry again, I should have thought about it right away but as always simple solutions are thought to be late ...

P.S. The title of the discussion has been changed.