Settings ignored in the wincmd.ini file

[petermad]

Hmm, I have at least 12 different TC installations (32- and 64bit) on at least 7 computeres, one of them has been operative for 21 years, most for 3-4 years and I have never encountered a duplicate [Configuration] section unless for a couple of rare occasions where the computer has crashed while writing to wincmd.ini - which has corrupted wincmd.ini - not necessarily with a duplicate [Configuration] section - but other corruptions.

[Tyler]

I am glad to learn that the problem was not just with me. The other poster pointed out that the settings under the first [Configuration] heading were ignored. And this is exactly what was happening with me.

Moreover, I never created a second [Configuration] heading by editing the file manually. I did edit the file manually, but I never created any section heading. Again, the other poster confirmed the same thing.

So, there is a problem with the program, which should be fixed.

At the very least it must be made sure that duplicated section headings are not created automatically by the program, leading to the problems described above.
Additional checks to make sure that manually edited headings are not duplicated would be a plus.

Off-topic comment: I am very new on this forum and I could not help noticing, both in this thread and in another thread, the dismissive attitude that goes like "well, this problem has not occurred in so many years..." or "this feature has not been requested in so many years...", which in my opinion does not make much sense as an argument. I sure hope it is not a trend here. No hard feelings.

[petermad]

2Tyler

So, there is a problem with the program, which should be fixed.

Sure, it should, but it is very difficult to fix a problem that one cannot reproduce.

"well, this problem has not occurred in so many years..." or "this feature has not been requested in so many years...", which in my opinion does not make much sense as an argument.

Well, the argument is that the error seems to be wery rare and obviously requires som special prerequisites, that you have, but not so many others.

[Dalai]

Apart from corruption, there's some other thing that could lead to duplicate section: a BOM (byte order mark), in particular if the file is (accidentally) encoded as UTF-8. The WinAPI functions might not find the keys requested by TC (due to the BOM that they don't expect) and create a new section when writing to the INI.

IIRC there were some issues with BOMs in the past. It's just some wild guess, though.

Regards
Dalai

[umbra]

Hi, guys. It's been a long time.

This issue is real. It happened to me as well. But only two or three times over the last couple of years. Every time, it was after copying my portable TC to a new computer and tuning a few settings for it. But not always - I could copy it to a dozens of computers and it would work just fine. So yes, reproducing it is not easy.

But this isn't the first time, someone mentioned it in this forum. If I remember correctly, there was a suspicion, that a BOM or some symbol before the section header prevented TC from recognizing it. I just can't find the topic ...

Edit: Looks like Dalai was faster

[FoxWolfie]

Apart from corruption, there's some other thing that could lead to duplicate section: a BOM (byte order mark), in particular if the file is (accidentally) encoded as UTF-8.

My .ini file is unicode, starting with bytes FF FE, with every character after that taking up two bytes.

If I make a new .ini, it is not unicode. Each character is one byte, and there is no BOM.

If I use TC's menu options to make changes, the .ini becomes unicode again, but not always. It sometimes requires using TC for an hour or so before it goes unicode on me. You possibly solved part of it. The duplicate [Configuration] section doesn't happen unless the file is unicode, from what I'm not seeing. Something in TC is determining when that happens, because I am purposely not doing any manual editing of the file while trying to figure out the cause. So far, I don't see the duplicate section in an .ini file that is still non-unicode, but they become unicode within a short period of my normal use of TC.

I routinely use the multi-rename tool with parameters that might be in other character sets, and I know that the search and replace history is stored in the .ini file. I guess I'll test to see if something as simple as a search and replace involving a non-ASCII character is enough to cause the .ini file to become unicode, and end up with a duplicate [Configuration] sections. Maybe it's just a coincidence.

[MVV]

TC uses Windows API for accessing INI, and API transparently supports both ANSI and Unicode (UTF-16) files, and TC only calls get/set functions.

Perhaps BOM could be a reason but it should work fine with UTF-16 BOM. I've resaved my wincmd.ini as UTF-16 with BOM and TC works just as with ANSI file, it doesn't create additional [Configuration] section when I change settings.

It is important to know/remember that UTF-8 is not supported by Windows INI files.

[petermad]

I know that the search and replace history is stored in the .ini file. I guess I'll test to see if something as simple as a search and replace involving a non-ASCII character is enough to cause the .ini file to become unicode

If that is the case a workaround could be to redirect the history related items to an external file - for example:

Code: Select all

[attrplugin]
RedirectSection=history.ini

[rename]
RedirectSection=history.ini

[SyncOptions]
RedirectSection=history.ini

[Selection]
RedirectSection=history.ini

[SearchName]
RedirectSection=history.ini

[SearchIn]
RedirectSection=history.ini

[SearchText]
RedirectSection=history.ini

[RenameTemplates]
RedirectSection=history.ini

[RenameSearchFind]
RedirectSection=history.ini

[RenameSearchReplace]
RedirectSection=history.ini

[left]
RedirectSection=history.ini

[right]
RedirectSection=history.ini

[lefttabs]
RedirectSection=history.ini

[righttabs]
RedirectSection=history.ini

[Command line history]
RedirectSection=history.ini

[RightHistory]
RedirectSection=history.ini

[LeftHistory]
RedirectSection=history.ini

[MkDirHistory]
RedirectSection=history.ini

See: http://ghisler.ch/board/viewtopic.php?p=145629#145629

That also gives the benefit of being able to share your wincmd.ini file whitout giving away personal history information.

[MVV]

I guess I'll test to see if something as simple as a search and replace involving a non-ASCII character is enough to cause the .ini file to become unicode

You should check your editor's preferences if it may silently change file encoding. My editor warns when I try to save Unicode characters to ANSI file, and it never adds BOM itself.

[FoxWolfie]

You should check your editor's preferences if it may silently change file encoding. My editor warns when I try to save Unicode characters to ANSI file, and it never adds BOM itself.

My editor also warns when saving non ANSI characters. That doesn't apply here though, since the issue occurs without any manual editing of the .ini file. All I need to do is to let TC make a new .ini file, which always appears normal, without a BOM, and with only one [Configuration] section. Then I go to options and start customizing TC to my preferences, saving settings, and start using TC to manage files. Somewhere in there, the .ini file gains FF FE bytes at the start, and a second [Configuration] section. At no time do I open or use my editor for this to happen.

It does not appear to be because I search for non-ASCII characters in the MRT, as that alone didn't trigger it when I tried testing. I still can't narrow down what actually causes it, as it seems to be random. Once the .ini file gets a duplicate section, it stays that way, but I would never notice it if I wasn't purposely looking at the file. TC behaves and saves settings normally. Nothing breaks in the program. The only time it would actually be an issue is if someone tried to insert manual settings, and they accidentally choose the wrong [Configuration] section. If they did, then the setting would be ignored.

As a test, I tried making a new .ini and immediately made some manual changes with my editor, exited, and restarted TC. That alone did not cause the section to duplicate, and TC honored the manual settings I made. It only happens when changing something, yet unknown, within TC's own options menu.

This issue doesn't really bother me, since it's so easy to work around. I only mentioned it as confirmation of the original poster's problem.

[MVV]

Somewhere in there, the .ini file gains FF FE bytes at the start, and a second [Configuration] section. At no time do I open or use my editor for this to happen.

Sounds strange because AFAIK TC never converts file to Unicode itself...
Anyway strong instructions required for reproducing this magical thing.

[FoxWolfie]

I still haven't narrowed down what causes it. However, I redirected all my history stuff to a history.ini, as suggested. I created the history file myself as a plain ANSI file and put some of the things I wanted to keep in it, such as my search and replace terms, and saved the file. I confirmed that there was no FF FE at the start of the file, and the file was about 5k. I also confirmed that TC was honoring the history.ini file.

I also resaved my wincmd.ini as plain ANSI, and merged the two [Configuration] sections, after having separated all the history from it. So far, it remains as ANSI, without the FF FE, and without the duplicate [Configuration] section.

Without touching the history.ini file, I exited and restarted TC. The history.ini file still remained ANSI, as did the wincmd.ini file. I then went into options and toggled some random settings, and clicked on OK. I exited TC and restarted, and now the history.ini file is 10k in size (double what it was), and has the FF FE at the start. The wincmd.ini file remains as ANSI. It seems that I shifted the issue from the main .ini file over to history.ini file. Whatever causes the conversion to unicode appears to have something to do with something in my various histories.

I guess I'll need to separate each history into its own .ini file for further testing, to see which, if any, ends up as unicode.

[MVV]

If it was Windows 8 or 10, I could think that it changes file encoding... but I haven't seen anything like this with Windows 7. And, TC itself stores Unicode strings in ANSI file as UTF-8 with BOM in the beginning of every string, I've just rechecked that. I have 3 INI files, main one, one with user-specific settings like colors and shortcurs and third one for the rest (histories etc), and all these files are in ANSI.

[Dalai]

I don't think that a Unicode BOM (FF FE) is an issue as the WinAPI transparently supports it - in the relevant GetPrivateProfileString and WritePrivateProfileString functions at least - as was already pointed out.

However, UTF-8 BOM (EF BB BF) might cause trouble as it is not supported by the API functions.

Regards
Dalai

[FoxWolfie]

I have not seen a UTF-8 BOM (EF BB BF) at the start of any of my .ini files so far.

My wincmd.ini file was auto converting to Unicode BOM (FF FE) with no manual editing. Now that I have redirected all of my history to a separate history.ini file, this is no longer happening. My wincmd.ini file is now remaining as ANSI, and the side effect of it ending up with duplicated [Configuration] sections seems to be solved - so far.

My history.ini file auto converts to Unicode though, even with no manual editing. It suggests that whatever triggers the conversion to Unicode has to do with something in my history. I simply moved the cause from wincmd.ini to history.ini.

Having my history.ini file auto converting to Unicode doesn't seem to be causing any negative issues so far. At least it doesn't appear to be duplicating any of the sections within it.