The file date of wincmd.ini is updated even though there have been no changes to it.

[JOUBE]

The file date of wincmd.ini is updated even though there have been no changes to it.

A truly annoying bug that makes synchronization difficult.

This unacceptable behavior hadn't occurred in previous versions for a long time.

That this bug has now reappeared is unnecessary and unforgivable, because it's pointless.

Until this bug is fixed, I advise against installing this version.

Please change before release version.

Joube

[ghisler(Author)]

Unfortunately this cannot be fixed, sorry. Windows will write a value to wincmd.ini even if it hasn't been changed. Manually reading each value before writing isn't feasible, because sometimes entire sections are written together.

Moderator message from: ghisler(Author) » 2026-04-14, 08:38 UTC

Moved to will not be changed

[Horst.Epp]

The file date of wincmd.ini is updated even though there have been no changes to it.

Until this bug is fixed, I advise against installing this version.
Joube

Strange reason to not install the actual RC3
What a big problem

[zhugecaomao]

Not face this issue.

But I suggest to use RedirectSection to relocate some sections which change frequently to another ini file.

for example:

Code: Select all

[Left]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[LeftHistory]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[LeftTabs]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[Right]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[RightHistory]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[Righttabs]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[LastTracks]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[MkDirHistory]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[NewFileHistory]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[Command line history]
RedirectSection=%COMMANDER_PATH%\User\%COMPUTERNAME%.ini

[ghisler(Author)]

There has been no change in RC3 which would cause more writes to wincmd.ini. What zhugecaomao suggests is a good idea.

[white]

Writability is checked when TC starts by writing a Firstmnu value to wincmd.ini, which changes the timestamp.

Firstmnu= Used to check writability of the wincmd.ini (like test=, but without error message)

If wincmd.ini is readonly, the file is unchanged and no error is displayed at startup. When TC needs to write to the readonly wincmd.ini later, an error is displayed.

The use of Firstmnu has been discussed, for example, in thread Why wincmd .ini ''firstmnu''-item change everytime? where Ghisler says:

Yes, it's a write check. And it should only happen once when TC starts. Do you constantly close and re-open TC?

The usefulness of this is not entirely clear to me. There doesn't seem to be much difference when simply assuming wincmd.ini is not writable at startup. Perhaps it is used for internal optimization, or perhaps for displaying one error message instead of multiple error messages for every fail to write a value to wincmd.ini. In any case, it does not seem necessary to do this at startup. I think it could also be done on first use of the check whether wincmd.ini was writable at startup.

[JOUBE]

Unfortunately this cannot be fixed, sorry. Windows will write a value to wincmd.ini even if it hasn't been changed. Manually reading each value before writing isn't feasible, because sometimes entire sections are written together.

It was probably just a temporary glitch in one of the systems here. Everything's fine now. Sorry.

What a big problem ...

Absolutely, one could even call it a catastrophic problem, if that were indeed the case. However, assessing such matters is beyond the experience of individuals and amateurs.