FreeCommander Forum

How to replicate the bug:

1] Create for example such files in those locations

C:\test\A▶\test file A.txt
C:\test\▶B\test file B.txt
C:\test\C\test file C.txt
C:\test\D\test file D.txt


2] Select option

Tools > Settings > File / folder operations > General > Copy > Use external program

and enter in its box

3] Navigate to

C:\test\

and switch in it to Plain View mode [CTRL+B]


4] Select any file from a folder with the ▶ sign and from a non-▶ folder [e.g. select test file A plus test file D]


5] Press CTRL+C and then execute CTRL+V in the opposite Panel that shows whatever folder [one of those 4 from the above paths or any other on your volumes]; or in a window of Windows Explorer


The result: [in this example] the test file D will be copied without a sweat while the test file A will cause TeraCopy to spit out the

Error opening source file. The filename, directory name, or volume label syntax is incorrect. Code: 123

message


Any other method / variant of copying seems to work A-OK i.e. when using Windows' native coping feature for such pasting in started from Plan View selection, when using Plan View and TeraCopy but for dragging of selected files and not for pasting them, when not using Plan View and selecting multiple files all located in a ▶ folder, etc.


I know that this looks like this is the sole fault of TeraCopy [because it also happens in Windows Explorer] - and if it is then I will post this bug on its forum. However: please notice that peculiar case when using dragging instead of pasting - because then there is no problem. And also if you select a single file while still using Plain View / TeraCopy combo and use the CTRL+C / CTRL+V method then the issue does not occur. So it seems that it is the FreeCommander that sends to memory incorrectly written path when a path happens to have such filled-triangle-pointing-right sign in it and when there is more than just one such path in such command. And if such dichotomy is happens to users of other external programs other than TeraCopy then this would be a further evidence that it is FC that is the culprit


I am using FreeCommander XE 2023 Build 912 64-bit Donor Portable & Build 901 32-bit Public Installed and TeraCopy 3.12.0 on Windows 10 Enterprise 20H2 x64 [10.0.19042]

I don't like to verify errors if the versions are not actual.
FC x64 is currently at version 9.28
Teracopy is 3.17 final or 4.0 TC

I have just tested this behavior using TeraCopy 3.17 and the latest FC donor version I have access to which is 926 - and it is the same

And with TeraCopy 4.0 RC it is even worse

Because [in the above example] instead of seeing an error for test file A and ending up wit at least the test file D having been copied, what I get is a brief change of standard mouse pointer to the one with hour glass - but in the end nothing really happens [i.e. my request is apparently acknowledged but nevertheless ignored]

I have just tested this behavior using TeraCopy 3.17 and the latest FC donor version I have access to which is 926 - and it is the same

I think, I have found small problem in FreeCommander.
I will fix it for the next release.

It should be fixed in 929.