Very long delays while navigating folders and disks

[Ghisler Commander]

Sorry for my broken English:)
If set WatchDirs = 1 and the CPU is used by about 100% of other applications, then there are very long delays while navigating folders and disks, up to hang Total Commander. Annoying bug appeared only in version 7.56. In 7.55a everything was normal.

[ghisler(Author)]

Can you give me more details, please? What is happening in the displayed directories? It sounds like some background programs are permanently changing files in the file lists, which keeps TC busy.

Edit: I have just checked my sources, and there seem to be only 3 changes to the watch dir code:
1. When a file is renamed, TC now checks whether the new name is already in the list, so it doesn't appear twice
2. When branch view with only the selected files/dirs is used, TC checks whether the new file name is part of that list
3. WatchDirs isn't suspended now when re-reading a directory, but it's still suspended as in TC 7.55a when changing to a different directory

[Ghisler Commander]

For example, when we try to enter into any folder, icon appears on the open folder and TC hangs for a few seconds, than the TC window is not available for any other action.
I would not say that there is a permanently change in the files as I ran the program, which loads only the processor. And the problem exists not only with regards to a specific folder. Stuck happens when we try to enter into any folder, even empty.
I recall that in version 7.55a everything worked without problems.
(Athlon XP 1800 MHz, Windows XP SP3)

[ghisler(Author)]

I have tried to reproduce your problem now on my old Pentium III 866MHz (single core), but without success: I have started packing a folder with some large files to zip (maximum compression), then put that in the background. In Task Manager, the CPU was at 100%, and the target file size was updating. I couldn't see any difference in speed when changing directories compared to TC 7.55a.

However, when there is heavy harddisk activity and the target directory is fragmented, it can take a while to enter the directory for the first time (but also when WatchDirs is off).

What did cause the 100% CPU on your system? Could you test with TC 7.55a whether it's slow now too? You can download it here if you don't have it any more:
https://plugins.ghisler.com/755a/tcmd755a.exe

[Ghisler Commander]

At home I have 2 computers with processors AMD Athlon, in both situations are identical. CPU at 100% I did through the program Winrar (Tools -> Benchmark and hardware test). Tested both versions 7.55a and 7.56 with the parameter WatchDirs = 1. Version 7.55a has worked as fast, version 7.56 brakes and hang. When set WatchDirs = 0, all problems have disappeared.

[ghisler(Author)]

I will try with WinRAR, thanks for the info.

[Ghisler Commander]

It seems to me, it's not quite matter which program you want to use that would load the CPU. I discovered this problem when running virtual machine. Winrar seemed to me the easiest way to get the processor to 100% without much straining the file system:)
On Russian-language forums, some people have also seen similar problems, but not all. And I got the impression that this is precisely the fate of processors Athlon.

[ghisler(Author)]

I have tried it now - wow, that really brings the rest of the system down. I also found out why it makes dir changes slow: TC tells the watchdirs thread to stop watching changes, and then waits until the tread stops. The problem is that the thread runs at a lower priority than the main thread, so it's not handled at all (or very rarely) at 100% CPU. I will try to find a better solution for TC 7.56a. Thanks for informing me about the slowdown!

[Ghisler Commander]

Glad to help you!

[Flint]

The problem was fixed in 7.56a, the topic can be moved to the "Fixed" subforum.

[ghisler(Author)]

Unfortunately I didn't get any feedback from the user. Can anyone else confirm the fix?

[Flint]

ghisler(Author)
The fix was also confirmed during the beta-test. Of course, let's wait for some time for the topic-starter to confirm it too, but even if he does not, I think the topic can be moved anyway.