Failed Move Triggers and Outcome?

[Cormy1]

I was moving files from 1 partition to another on the same drive with verification.
About 95% of the way through Total Commander failed on a file with japanese characters in the filename.
I figured whatever, I'll just finish moving the rest of the files with File Explorer.
Nope.
Total Commander did not leave the remaining 5% of files intact in their old location, they're just gone.
EDIT:
I have confirmed that the japanese file was copied over so now I'm even more confused about what occurred.
So did it actually complete moving the files or not?

What triggers file move failures? Was it the file verification that failed?
I have almost no way of verifying what happened to the remaining 5% of the move process.

[petermad]

By default, if TC does not need interaction after the first 5 seconds of a copy or move process, TC will present the files that needed interaction at the end of the process when all other files are copied - it is configurable:

SkippedFileCopy=1 1: First copy all files where the user doesn't need to be asked and skip all with errors, ask at the end
0: Copy all files in order, ask for confirmation when needed
>=100: Like 1, but sets number of milliseconds at start during which the user will be asked too (default 5000)

So it is most likely that all your files were moved.

[Cormy1]

This doesn't address the copy failure.
What could have occurred to cause a copy failure and what would the result normally be?
I assume the failure causes an exit code, since it's not like there was any prompt to attempt the copy a second time or anything.
I don't even know if the failure was caused by a "file that needed interaction" of if there was simply a random bug (e.g. memory corruption for example) that occurred.

[petermad]

What could have occurred to cause a copy failure

Do you remember the message you recieved when TC showed that it could not copy the file with Japanese characters?

[Cormy1]

As far as I recall the only message was that it failed, no details, otherwise I might've written it down. The only thing I noted was the file that it seemed to fail on so I could at least double check that.
It didn't give me any details at all.
That's what makes this so "scary" for me.
Don't think we'll be able to "diagnose" this, just need to know SOME common failure modes that you can think of I guess, that I can check.

I have continued copying files today and ran into another issue.
Total Commander tried to copy a file which Windows Defender flagged as a virus and quarantined, making the copy fail.
Okay fine, I unquarantine the item and tell total commander to try again.
It tries again and Defender quarantines it again.
I realize I need to whitelist the file, so I do that and then restore it again.
But this time Total Commander doesn't give me an option to try again, I can only ignore or abort the error.
Very annoying.

Also you say that TC should copy all files that don't require user input first, but I keep running into these problems in the middle of my copy processes.
Additionally, when I handle the prompts, there is still lots of copying left to be done.
This quarantine problem was hit within the first 5% of a move operation and after handling the prompt, there was still lots of work to be done without prompts.

[Horst.Epp]

This quarantine problem was hit within the first 5% of a move operation and after handling the prompt, there was still lots of work to be done without prompts.

And why is it a problem of TC if you don't handle your Anti-Virus tool correctly.

[petermad]

2Cormy1

just need to know SOME common failure modes that you can think of I guess

Most common reasons for TC not moving a file is that it is a read-only, system or hidden file - in that case TC will ask whether you want to delete the source file after it is copied.

Then TC might fail moving if the target path ends up being longer the 259 characters - that can be solved by using the LongNameCopy parameter in the [configuration] section of your wincmd.ini file:

LongNameCopy=0 During file operations, warn if target name is longer than 259 characters:
0=always
1=never
2=if source name isn't longer than 259 characters
3=disallow long names

And then TC might fail moving a file if you don't have the user-rights to access the file (for example files in "C:\Program Files")
And then of course there can be hardware failure with unreadable sectors.
And antivirus programs might lock the file so it cannot be moved.

[Cormy1]

This quarantine problem was hit within the first 5% of a move operation and after handling the prompt, there was still lots of work to be done without prompts.

And why is it a problem of TC if you don't handle your Anti-Virus tool correctly.

...?
Because the problem isn't with the anti-virus, it's with TC not giving me the option to try an operation again?
Not that that matters, because my point was just that operations that cause prompts do not occur at the end of a batch operation, as suggested by the other user.
I'm not asking TC to interfere with the anti-virus and stop such prompts from occurring, the prompts are fine.

2Cormy1

just need to know SOME common failure modes that you can think of I guess

Most common reasons for TC not moving a file is that it is a read-only, system or hidden file - in that case TC will ask whether you want to delete the source file after it is copied.

Then TC might fail moving if the target path ends up being longer the 259 characters - that can be solved by using the LongNameCopy parameter in the [configuration] section of your wincmd.ini file:

LongNameCopy=0 During file operations, warn if target name is longer than 259 characters:
0=always
1=never
2=if source name isn't longer than 259 characters
3=disallow long names

And then TC might fail moving a file if you don't have the user-rights to access the file (for example files in "C:\Program Files")
And then of course there can be hardware failure with unreadable sectors.
And antivirus programs might lock the file so it cannot be moved.

I'm not asking for reasons TC won't move a file.
I'm asking for what causes FAILURE.
It is a specific dialog.
Read-only files do not cause failure dialogs, TC tells you it is read-only and asks you how to proceed.
The same goes for system, hidden, long names, user permission problems and locked files.
Unreadable sectors would be the only one that would make any sense to me, but only because as far as I'm aware, I haven't experienced it yet so I don't know what the dialog for it looks like. I'd wager it informs you that it couldn't read the file though.

[petermad]

2Cormy1

It is a specific dialog.

And that is why we ask for the message in that dialog, how else can your problem be adressed? Was it even a TC message or was it a system mesage?

[Dalai]

Unreadable sectors would be the only one that would make any sense to me [...]

Unreadable files is similar to this. What do I mean by that? Well, files that were opened successfully but there's some error while reading the file. This can have several reasons, only one of which is anti-virus software, others are drivers, hardware issues (drive, network etc.) and the list goes on.

TC makes a difference if an error occurs when opening a file or while reading it. Only the former kind causes TC to continue with the next file and ask the user what to do at the end of the operation.

[Cormy1]

2Cormy1

It is a specific dialog.

And that is why we ask for the message in that dialog, how else can your problem be adressed? Was it even a TC message or was it a system mesage?

It was a TC message, as I mentioned it simply stopped the copying process when the error occurred. TC did not crash, Windows did not report anything wrong. Only the copy operation dialogs went away. I just had the copy running as part of a queue.
It was a generic failure dialog. It never specified which file caused the error, and it never said what the problem was. I only guessed which file it MIGHT be based on where it APPEARED to be in the copy process based on the copy operation progress status bar.

Unreadable sectors would be the only one that would make any sense to me [...]

Unreadable files is similar to this. What do I mean by that? Well, files that were opened successfully but there's some error while reading the file. This can have several reasons, only one of which is anti-virus software, others are drivers, hardware issues (drive, network etc.) and the list goes on.

TC makes a difference if an error occurs when opening a file or while reading it. Only the former kind causes TC to continue with the next file and ask the user what to do at the end of the operation.

So an error while reading the file would cause the operation to abort...?

I tried to re-create the error but was unable to so I probably won't ever figure this out.

[Dalai]

So an error while reading the file would cause the operation to abort...?

No, it doesn't cause the operation to be aborted but interrupted, i.e. TC asks the user what to do with the file.

[petermad]

2Cormy1

I tried to re-create the error but was unable to so I probably won't ever figure this out.

You could turn on TC's file operation log file, then if it should happen again you would be able to see at which file the problem occurred.