[8.01] corrupted COMMANDER_PATH

[sgp]

To reproduce this issue you need:
a) Some way to set a volatile environment variable in the registry
b) Some way to broadcast message WM_SETTINGCHANGE
c) Two copies of TotalCommander in different folders. Let's call them TC1 and TC2
d) Sysinternal's Process Explorer.

Issue description:
%COMMANDER_PATH% in TC2's memory silently changes from pointing to TC2's own folder to pointing to TC1's folder. Tested on Win7 SP1 32-bit.
I think this is an issue because COMMANDER_PATH ends up pointing to the wrong folder so portable paths are broken from that point on. The user doesn't know about the change of COMMANDER_PATH's value. S/he just notices that bar buttons that rely on COMMANDER_PATH fail starting the right programs.

Steps to reproduce:
1) Close all TC windows
2) Open CMD and set volatile variable COMMANDER_PATH to point to TC1's folder. So now we have a COMMANDER_PATH in the registry.
3) Start TC1 and verify (with procexp) that its in-process COMMANDER_PATH points to TC1 as it should.
4) Start TC2 and verify (with procexp) that its in-process COMMANDER_PATH points to TC2 as it should.
5) Now broadcast message WM_SETTINGCHANGE. This makes both TC1 and TC2 update their environment. It seems that TC2 (probably TC1 also) resets its in-process COMMANDER_PATH from the volatile registry. Unfortunately, the registry value points to TC1's folder, so TC2's COMMANDER_PATH now points to TC1's folder.

Proposed fix:
I think that when TC acts on a WM_SETTINGCHANGE message it should not update the values of COMMANDER_PATH, COMMANDER_INI, COMMANDER_DRIVE.

[ghisler(Author)]

Some way to set a volatile environment variable in the registry

How do you do that? I have never seen variables created by TC in any other programs. But I agree that TC shouldn't change these variables when they are set in other programs, e.g. in cmd.exe.

[sgp]

Some way to set a volatile environment variable in the registry

How do you do that?

I set a volatile variable in the registry with JPsoft's freeware Take Command LE command prompt version 13.04.63, x32 ftp://ftp.jpsoft.com/tccle/tccle.exe ,x64 ftp://ftp.jpsoft.com/tccle/tccle64.exe
From the TCCLE prompt type SET /V varname=value. SET /V by itself lists all volatile registry variables. In order to push a change to listening applications you need to broadcast WM_SETTINGCHANGE. I believe SET /V a=b conveniently does it, and TC listens.

I have never seen variables created by TC in any other programs.

Actually I reported the opposite, that is, an issue with another program affecting the variables inside TC.

But I agree that TC shouldn't change these variables when they are set in other programs, e.g. in cmd.exe.

Do you see any reason for TC to change its internal COMMANDER_* variables once they're set? I really don't.

The RegistryEx plugin can change TC's variables, but that's a deliberate user's choice - it's a different story.

[ghisler(Author)]

Do you see any reason for TC to change its internal COMMANDER_* variables once they're set? I really don't.

No I don't - I just didn't make any distinction between TC's variables and system variables, because normally no one pushes TC variables to other programs. They are usually only set by TC instances internally, and not pushed to other TC instances. You can try this:
1. Start first TC from one dir
2. Launch command
cd %commander_path%
3. Start second TC from other dir
4. Switch back to first TC
5. Launch again command
cd %commander_path%

-> we still go to the dir of that instance, not the dir of the other.

[sgp]

I just didn't make any distinction between TC's variables and system variables, because normally no one pushes TC variables to other programs. They are usually only set by TC instances internally, and not pushed to other TC instances.

I understand and agree.