+TC8.51b5 repeats the attempt to copy-move in case of error?

retalv · Post by *retalv » 2014-04-02, 08:50 UTC

Sorry, is a strange thing happened when copying a DVD ISO image.
Is difficult ( impossible for me ) reproducible, but anyway as I communicate information, let me explain ...

Probably the Debian ISO image, downloaded via torrent, it appeared corrupt though apparently passed all the tests CRC made later (with the new image is downloaded, the problem has not resurfaced) or had corrupted the filesystem (even if the chkdsk confirmed the disks as intact).

Being copied-moved (default copy-move options) on different disk, reached 96% and without error messages the copy began again from the beginning and only after reaching 96% the operation ended with an error message about the impossibility of writing(!?), suggesting to check if the file was write-protected or locked by an application... NOT on reading.

Obviously the result was a systematic error (antivirus and similar disabled) even after a system reboot, fixed only by downloading the image file again using jigdo (for safety).

The strange thing is the second attempt to copy after the obvious error and the error message that should be in writing (in case) appear immediately.

As is normal behavior?

Thank you!

Post by *Hacker » 2014-04-02, 10:09 UTC

Hello retalv,
What was the copy method?
Can you reproduce the behavior?

Roman

retalv · Post by *retalv » 2014-04-02, 12:21 UTC

Your questions are answered in reading the opening post.

The functions of copy-move are the default ones.

As already mentioned, the error is probably due to the corrupt file, can not be reproduced except by an equally corrupt file. The fact is that the fault management function exists and copy files from the correct format does not occur.

Without polemic, if I make a crash with the car because a tire exploded while driving due to a pothole, it is at least bizarre ask for evidence that the tire exploded to start a check on the reliability of the tire, do not you think?

Post by *Hacker » 2014-04-02, 13:09 UTC

retalv,
OK, let me be more specific - did you copy using F5? Drag and Drop? Ctrl-C -> Ctrl-V?
Did you use the 32-bit or 64-bit version of TC?
What Windows version did you use?

Without polemic, if I make a crash with the car because a tire exploded while driving due to a pothole, it is at least bizarre ask for evidence that the tire exploded to start a check on the reliability of the tire, do not you think?

Well, as I am not asking for evidence, I hope you don't mind if I ask what tyre it was on what model of what car.

Roman

retalv · Post by *retalv » 2014-04-02, 13:58 UTC

You're right ...

Hacker wrote:OK, let me be more specific - did you copy using F5? Drag and Drop? Ctrl-C -> Ctrl-V?

F5 & F6 only

Hacker wrote:Did you use the 32-bit or 64-bit version of TC?
What Windows version did you use?

TC 64 bit
Windows 7 Pro (obviously 64 bit)

Hacker wrote:
Without polemic, if I make a crash with the car because a tire exploded while driving due to a pothole, it is at least bizarre ask for evidence that the tire exploded to start a check on the reliability of the tire, do not you think?
Well, as I am not asking for evidence, I hope you don't mind if I ask what tyre it was on what model of what car.

OK, now we understand each ...

Post by *ghisler(Author) » 2014-04-02, 19:18 UTC

This isn't really a bug, it's happening because of the new function to handle errors at the end of the operation. So when there is an error in the middle of copying a file, TC will continue with all other files and handle the problems at the end.

In case of failed copying, TC will try again to copy the file, because it may have been a temporary problem (e.g. file locked by other process). Of course this doesn't make much sense when you copy just a single file. Therefore I will change this behaviour when there is an error when copying the LAST selected file.