TC10.50b1: Copy/Move occasionally hangs

[deus-ex]

I experienced a couple of times that TC10.50b1 hangs/fails to copy or move files on the same drive, whereas TC v10.0 works without any issues. For safety reasons, I have returned to TC v10.0 for now. Please let me know if I can assist in finding the root cause of the issue, I'm happy to help.

I'm running Windows 10 Pro 64-bit 21H with all recent official updates (build 19044.1645), TC 10.x 64-bit in normal (non-dark) mode.

[ghisler(Author)]

Sorry, I have never seen this problem. Anyone else?

[petermad]

Anyone else?

Not unless it is related to this: https://www.ghisler.ch/board/viewtopic.php?t=76305 - which I doubt.

[deus-ex]

2petermad

Thanks for your input. My issue does not involve working with archives, but I am using a different interface language for TC indeed (German), whereas my system language is set to English.

The copy/move fail appears on different occasions, for example, one time trying to move just one small file (~40KB), another time when copying several small files (~10 files, each ~100-300KB). I cannot detect any pattern to the issue which makes it rather difficult to find the root cause, I wonder though if the following two wincmd.ini entries have any effect on this since the TCs copy/move routines appear to have been overhauled.

Excerpt from my wincdmd.ini:

Code: Select all

[Configuration]
CopyBlockSize=20480
CopyBlockSizeOther=128

[pulbitz]

I also experienced.
I can't remember if it happened on Windows 11 or 10. (both in dark mode)

[ghisler(Author)]

2pulbitz
Maybe your problem is related to this report:
https://www.ghisler.ch/board/viewtopic.php?t=76287

[pulbitz]

1. Folder with large number of files (example. Windows\WinSxS)
2. Press F5 + Enter (better to presss quickly)

I'm not sure under what conditions the bug occurs.
Please view a capture file. (Copy_Move occasionally hangs.gif)
https://file2.me/d/2ccp61

[AntonyD]

1. Folder with large number of files (example. Windows\WinSxS)
2. Press F5 + Enter (better to presss quickly)

I'm not sure under what conditions the bug occurs.
Please view a capture file. (Copy_Move occasionally hangs.gif)
https://file2.me/d/2ccp61

I am not an author - but I would like to ask - is that a file hosting service the only one which you can use?
It's not intuitive and no user-friendly for all non-native people, imho.
Also why for the screening you had used GIF file? We can't put on a pause the playing process of this file.
But we must do that in order to analyze some info on your screen.

Is is a normal behavior for your OS/chosen locale that the ASCII char '\' was shown as strikethrough letter W?
Also how long did you try to wait? In my test in this catalog I must wait at least 10|15 sec before copy process will start.
Also it's strange that there is no the process of calculating the amount of files/folders on yours F5 form.
By default it should be done in a parallel thread. Thus we for sure SHOULD be able to see the start at least of that process,
but your short gif does not show it to us...

2*ghisler(Author)
btw looks like this form F5|F6 copy/move now contains another bug - after the completing the separate calculating the overall numbers of files and folders it shows wrong number for folders - always +1! Even in case when there is NO any subfolder in the selected element on a panel.
For ex, path: c:\Windows\WinSxS\Backup\ contains only 1585 files and 0 subfolders. When I will start to copy Backup\ folder to the destination c:\TEMP\ - I will see that your calculating process will show to me 1585 files AND! ONE! subfolder - which is completely wrong!
ALSO - WHY you show to me K/M/G - BYTES on this form then I had chosen to use pure real bytes in settings? OR "size display" OR "Header/footer" settings MUST be applied on this form also!

[Usher]

https://file2.me/d/2ccp61

Is is a normal behavior for your OS/chosen locale that the ASCII char '\' was shown as strikethrough letter W?

That site is in Korean. It's a backward compatibility (mis)feature for Japanese and Korean. Backslash character ("\") unused in these languages is replaced with currency symbol: Japanese yen (¥) or Korean won (₩) depending on codepage used. It's been already explained for Japanese case here:
https://www.ghisler.ch/board/viewtopic.php?t=51822

For ex, path: c:\Windows\WinSxS\Backup\ contains only 1585 files and 0 subfolders.

There is no SUBfolders, but there is ONE folder, which will be copied if you don't enter inside it.

[pulbitz]

1. Folder with large number of files (example. Windows\WinSxS)
2. Press F5 + Enter (better to presss quickly)

I'm not sure under what conditions the bug occurs.
Please view a capture file. (Copy_Move occasionally hangs.gif)
https://file2.me/d/2ccp61

I am not an author - but I would like to ask - is that a file hosting service the only one which you can use?
It's not intuitive and no user-friendly for all non-native people, imho.
Also why for the screening you had used GIF file? We can't put on a pause the playing process of this file.
But we must do that in order to analyze some info on your screen.

Is is a normal behavior for your OS/chosen locale that the ASCII char '\' was shown as strikethrough letter W?
Also how long did you try to wait? In my test in this catalog I must wait at least 10|15 sec before copy process will start.
Also it's strange that there is no the process of calculating the amount of files/folders on yours F5 form.
By default it should be done in a parallel thread. Thus we for sure SHOULD be able to see the start at least of that process,
but your short gif does not show it to us...

It's difficult to explain because I'm not good at English.

You can convert easily gif to mp4 online.
https://ezgif.com/gif-to-mp4

or _Copy_Move_occasionally_hangs.mp4 download
https://file2.me/d/2cdmfc

Especially when copying a migration.xml file(only 78866 bytes), it's very strange.

1. F5 + Enter -> hang
2. F5 + F2 Queue -> copied
3. F5 + Options + OK -> copied

[ghisler(Author)]

2pulbitz
Thanks a lot for the video, doing F5+Enter very quickly while automatic folder size calculation is turned off allowed me to reproduce the error.
I will fix it in beta 3.

Don't worry, GIF is completely fine for showing the error. I also had no problems finding out which is the download button on the file2.me, although I don't understand Korean.

To avoid the hang for now in beta 2, please add the following line under [Configuration] in file wincmd.ini:
CountMarkedInDialog=0

You can edit the file via menu Configuration - Change settings files directly.
After editing and saving the file, you need to close and re-open Total Commander.

[deus-ex]

I'm currently trying out beta 2 of v10.50 in parallel to v10.00. Yesterday I witnessed the same issue again, trying to copy a single file with v10.50b2, the progress bar of the copy dialog remained empty for a couple of seconds, then the copy process finished. At least this is an improvement to v10.50b1, where the copy process would just stall but still could be canceled.

I was able to repeatedly reproduce this issue. When starting TC v10.00 in parallel to copy the same file, I had no issues.

[ghisler(Author)]

As I wrote one post above yours, I can reproduce it now, and will fix it in Beta 3. The reason is that the background size calculation thread tries to send results to the foreground window, which is already gone. This results in a timeout of a few seconds.

[Usher]

It may be even a few minutes in a directory with many thousands of files. Just got it in beta2.

[deus-ex]

As I wrote one post above yours, I can reproduce it now, and will fix it in Beta 3. The reason is that the background size calculation thread tries to send results to the foreground window, which is already gone. This results in a timeout of a few seconds.

Yes, thank you, Christian, I read that. I was hoping that your fix for beta 3 is related but I wasn't sure, so I figured I better post a report. Looking forward to your next beta then.