TC11.00beta7 issue with SyncDirs

[georgeb]

While hunting down another recent issue (already acknowledged and to be fixed soon) I stumbled upon another issue by accident, this time concerning the SyncDirs process.

In an effort to isolate the other recent problem I decided to perform a new, virgin installation of TC11b7 so that I could then compare the two instances ("virgin" and "production") step by step using the SyncDirs process from the newly created virgin instance of TC and subsequently trying to merge the two instances by trial and error in a systematic and reversible pattern so as to narrow down the file or files that would make the malfunction observed occur or go away respectively.

At one interim point of comparison I had for example (apart from hundreds of identical files already masked by deselecting them via the correlated top-button) 32 different files and 5 files "unique left" as well as several "unique right"-files not of interest for that purpose.

The strange thing was - while SyncDirs still seems to operate normally under the "production version" of TC11b7 - that with the virgin instance of TC11b7 with an equally virgin "wincmd.ini" both the 32 "different files" AND the 5 files "unique left" came up in green color (indicating "unique left") and pre-selected for copying left to right. None of the 32 "different files" could be de-/selected via the corresponding red selection-button at the top while the green selection-button (corresponding to "unique left") now erroneously would make all 37 files go away or re-appear altogether.

This leads to the conclusion that with a virgin "wincmd.ini" freshly created upon installation of TC11b7 (and probably earlier versions as I've just stumbled upon this issue by accident) TC11b7-SyncDirs will represent these two main categories ("different" and "unique left"") in some improperly garbled, erroneously merged-together fashion in the main window while correctly identifying their numbers in the bottom-status-bar. And before anyone might ask - this time the issue occurs regardless of whether or nor TC is run as Admin or in normal user-mode.

Anyone else having observed similar unusual phenomena with TC11b7-SyncDirs?

[petermad]

I cannot reproduce this, Syncronizing with my "production" wincmd.ini and a "virgin" wincmd.ini gives the same result.

Is there a chance you could proviode some screenshots of the two different outcomes?

[georgeb]

Addendum:
Ok, perhaps the answer to this strange observation may lie in the proper way of creating a "virgin" installation with an equally "virgin" 'wincmd.ini' for testing purposes.

I really thought that would be an easy one - just select 'install normally' from the installation menu, select a new installation-Dir and follow the screens to come - but apparently not so. To my surprise after doing so the new instance looked almost like my production-installation. All the colors were there as were all my familiar tabs, shortcuts and so on. Although this had become an unregistered installation as expected the look and feel couldn't have been further apart from what you would expect from a "virgin"-instance.

To remedy this I decided to delete the newly generated 'wincmd.ini', killed the TC-task via taskman and re-started TC. It now came up pretty much devoid of any individualized settings albeit to my even greater amazement my customary tabs (having been stored in the deleted original 'wincmd.ini') were still there from seemingly out of nowhere.

So there must have been some interference from the 'mother-wincmd.ini' from my production-version (still being located in its original TotalCmd-Dir) in spite of my principal installation-directory-setting for 'wincmd.ini' having always been the program-directory itself with the exact purpose to avoid such side-effects.

Anyhow precisely from then on the strange behavior of SyncDirs started to occur. So if there is a different way for properly creating a "virgin"-'wincmd.ini' I'd like to know and then test if SyncDirs would behave properly again.

[petermad]

2georgeb

You don't have to do all that just start Total Commander with the parameter /i=%TEMP%\virgin.ini

albeit to my even greater amazement my customary tabs (having been stored in the deleted original 'wincmd.ini') were still there from seemingly out of nowhere.

If that is the case, you are not using a virgin wincmd.ini. Where was the wincmd.ini file you deleted located. Did you in your original wincmd.ini have the line: UseIniInProgramDir=7.

TC will use wincmd.ini in various locations depending on choices made when installing TC - you can always see the location of the ini files for the current TC session via the menu: Help -> About Total Commander (the Help menu item is all the way to the right side of the menu-bar)

[georgeb]

I cannot reproduce this, Syncronizing with my "production" wincmd.ini and a "virgin" wincmd.ini gives the same result.

Is there a chance you could proviode some screenshots of the two different outcomes?

I'm afraid screenshots would be rather meaningless for people unfamiliar with my data-structure. Besides what information could be gained from the "different" files NOT showing up in red but in green as well. If you do not know which ones the "different" files are it would be hard to tell them apart from the truly "unique left"-files correctly shown in green as well.

More important - considering my additional remarks just published - would be to know how you created this "virgin" wincmd.ini. From earlier times I do remember that deleting the present 'wincmd.ini' was enough to let TC generate a truly "barebone"-'wincmd.ini' by itself upon restart.

But apparently this must have changed somehow. So perhaps you could delete your "virgin"-'wincmd.ini' for testing purposes and restart TC to look if the (mis-)behavior described above could be reproduced then?

[petermad]

Are you sure you use the same Synchronize settings for "by content" and "ignore date" in the two scenarios?

From earlier times I do remember that deleting the present 'wincmd.ini' was enough to let TC generate a truly "barebone"-'wincmd.ini' by itself upon restart.

Which wincmd.ini you have to delete depends on setting in Windows Registry - and if you have a wincmd.ini located in TC's program directory it depends on the presence and value of UseIniInProgramDir in the current wincmd.ini.

Please open "Help" -> "About Total Commander" and tell us the location of your wincmd.ini file as informed in that dialog.

Please start TC with the parameter /i=%TEMP%\virgin.ini and test the Sync. tool again.

[Dalai]

More important - considering my additional remarks just published - would be to know how you created this "virgin" wincmd.ini.

There's nothing special to do here. If TC is started with /i= and that path points to a non-existing file, TC will create that specified file and store its settings there.

From earlier times I do remember that deleting the present 'wincmd.ini' was enough to let TC generate a truly "barebone"-'wincmd.ini' by itself upon restart.

Yes, that's one way to do it. But it has (obviously) an influence on the wincmd.ini in use. This isn't the case with the /i= command line switch.

Regards
Dalai

[georgeb]

You don't have to do all that just start Total Commander with the parameter /i=%TEMP%\virgin.ini

Will try.

If that is the case, you are not using a virgin wincmd.ini. Where was the wincmd.ini file you deleted located. Did you in your original wincmd.ini have the line: UseIniInProgramDir=7.

My 'wincmd.ini'-files for all instances are located in the respective program-Dir since 20+ years now with the exact purpose of avoiding side-effects and, yes, UseIniInProgramDir=7 is set in there. So of course I deleted the newly generated one in the new program-dir.

TC will use wincmd.ini in various locations depending on choices made when installing TC - you can always see the location of the ini files for the current TC session via the menu: Help -> About Total Commander (the Help menu item is all the way to the right side of the menu-bar)

I'm not that much of a newbie to not having known that one. And again - whenever I install a new TC-instance the 'wincmd.ini' will always go to the (new) program-dir. This setting is also pre-set in the TC-installation-dialog. It couldn't be more unambiguous.

[petermad]

2georgeb

If you do not know which ones the "different" files are it would be hard to tell them apart from the truly "unique left"-files correctly shown in green as well.

If you don't have the two options "by content" and "ignore date" enabled I can see if from the size and date of the files.

Be aware that if you delete wincmd.ini from inside the running TC, and you have the options in "Operation" -> "Save on exit" enabled, those settings will be transferred to the newly generated wincmd.ini when you restart TC - so the wincmd.ini will not be "virgin".

[georgeb]

Are you sure you use the same Synchronize settings for "by content" and "ignore date" in the two scenarios?

Yes

Which wincmd.ini you have to delete depends on setting in Windows Registry - and if you have a wincmd.ini located in TC's program directory it depends on the presence and value of UseIniInProgramDir in the current wincmd.ini.
Please open "Help" -> "About Total Commander" and tell us the location of your wincmd.ini file as informed in that dialog.

wincmd.ini IS located in TC's program directory, UseIniInProgramDir=7 and help says (as expected) 'C:\WINTOOL\NewInstallDirName\wincmd.ini'

Please start TC with the parameter /i=%TEMP%\virgin.ini and test the Sync. tool again.

Will try as announced.

[petermad]

BTW, when you start TC with a virgin (auto created) wincmd.ini , you will always be met with a dialog box where you have to choose the default icon library - if you don't see that, you are not using a virgin wincmd.ini.

Also if you just delete your current wincmd.ini with UseIniInProgramDir=7 in it - that information is lost when you start TC, and TC might most likely use %APPDATA%\Ghisler\wincmd.ini

This if why it is much better to use the /i start parameter, then you know for sure which ini file TC will be using for the test.

[georgeb]

Yes, that's one way to do it. But it has (obviously) an influence on the wincmd.ini in use. This isn't the case with the /i= command line switch.

Thanks for acknowledging that. And to avoid any side effects I did terminate TC via taskman after deleting its own wincmd.ini so as to avoid writing back the old one upon exit.

Upon restart there was indeed a much smaller, almost feature-less wincmd.ini generated - apart from the strange fact that the tabs (and only the tabs) were still there from the previous environment. But exactly from then on the SyncDirs-problems started to show.

[georgeb]

Be aware that if you delete wincmd.ini from inside the running TC, and you have the options in "Operation" -> "Save on exit" enabled, those settings will be transferred to the newly generated wincmd.ini when you restart TC - so the wincmd.ini will not be "virgin".

Oh, it will be because as a precaution - as already described - after deleting its own 'wincmd.ini' I did of course terminate the TC currently running via taskman as to avoid writing back its old 'wincmd.ini' upon exit.

[georgeb]

BTW, when you start TC with a virgin (auto created) wincmd.ini , you will always be met with a dialog box where you have to choose the default icon library - if you don't see that, you are not using a virgin wincmd.ini.

Don't worry. I knew that and the icon-dialog-box DID show up on re-start.

[petermad]

I did of course terminate the TC currently running via taskman as to avoid writing back its old 'wincmd.ini' upon exit.

And still your Folder tabs were preserved - that is contradictory ???