Varying location of default.bar

[Zerryk]

9.20 b2 64bit, Windows 10 1803 CZ
HKCU\Software\Ghisler\Total Commander:
InstallDir=C:\Program Files\totalcmd
IniFileName=%APPDATA%\GHISLER\wincmd.ini

When TC is installed in Program Files, it uses default.bar stored together with wincmd.ini in AppData. When TC is run as admin, it uses default.bar in the program folder. The result is, when you modify the button bar in non-admin mode, the changes are not shared in admin mode and vice versa.

The button.bar file should be always stored together with wincmd.ini, if no explicit file is specified in [Buttonbar] config section, I think.

[ghisler(Author)]

This is intentional: When TC cannot write to the bar in the program directory, it has to copy it elsewhere and use it from there. This problem doesn't exist when TC is installed in c:\totalcmd as suggested by the installer.

You can manually change the bar location via Configuration - Button bar if you want to use the same file in both cases.

[MarcinW]

I can fully reproduce the problem, that Zerryk described.

I have TC installed in C:\Program Files\Total Commander.

When I start TC in a normal way, TC writes to files:
c:\Users\X\AppData\Roaming\GHISLER\WINCMD.INI
c:\Users\X\AppData\Roaming\GHISLER\default.bar

When I start TC in an administrator mode, TC writes to files:
c:\Users\X\AppData\Roaming\GHISLER\WINCMD.INI
c:\Program Files\Total Commander\default.bar


In both cases, TC has reading and writing rights to c:\Users\X\AppData\Roaming\GHISLER\.

And in both cases default.bar should be read from and written to c:\Users\X\AppData\Roaming\GHISLER\.

Regards

[sqa_wizard]

I prefer not to use the original default.bar, but use my own default.bar at my own location.

Just enter the fix location to your wincmd.ini:

Code: Select all

[Buttonbar]
Buttonbar=%APPDATA%\GHISLER\MyDefault.bar

[ButtonbarVertical]
Buttonbar=%APPDATA%\GHISLER\MyVertical.bar

[MarcinW]

Ok, but this should be treated as a possible workaround only.

It would be better to fix the original problem, though.

[MVV]

In both cases, TC has reading and writing rights to c:\Users\X\AppData\Roaming\GHISLER\.

And in both cases default.bar should be read from and written to c:\Users\X\AppData\Roaming\GHISLER\.

But TC doesn't have writing rights to c:\Program Files\Total Commander\default.bar when running w/o admin rights, and its location is not controlled by INI relocation settings, its default location is always in TC dir. I agree that it is a strange inconsistency and it would be better to warn user that TC can't write BAR file as TC does when it can't write INI.

[MarcinW]

But TC doesn't have writing rights to c:\Program Files\Total Commander\default.bar when running w/o admin rights

That's why I wrote it should always write to c:\Users\X\AppData\Roaming\GHISLER\

We are talking about writing, but there is much more simple problem: reading. TC always has reading rights to c:\Users\X\AppData\Roaming\GHISLER\default.bar, but doesn't read it when launched with administrator rights - result: existing default.bar is completely ignored and TC starts with default button bar configuration.

[MarcinW]

and its location is not controlled by INI relocation settings

Ok, but it's much more rare case, when INI is redirected, than when it's not redirected.

And, also, TC could handle redirection by reading redirection settings of INI from registry and using them also for default.bar? (I'm not an expert here)

[DrShark]

But TC doesn't have writing rights to c:\Program Files\Total Commander\default.bar when running w/o admin rights

That's why I wrote it should always write to c:\Users\X\AppData\Roaming\GHISLER\

Obviously there are existing TC insatallations with manually granted wright rights for bar writing to not-elevated TC in Program Files. I think in such a case TC should still use the bar from Program Files, so user won't have own custom bar changes lost.

[MarcinW]

in such a case TC should still use the bar from Program Files, so user won't have own custom bar changes lost.

But when writing to c:\Users\X\AppData\Roaming\GHISLER\, changes also won't be lost. And this will work always - not only when launched in administrator mode, or when directory access rights have been modified.

Regards

[DrShark]

But when writing to c:\Users\X\AppData\Roaming\GHISLER\, changes also won't be lost.

What I mean is: if in existing installation TC is using the bar files from Program Files for which user granted wright rights, and new TC version will prefer AppData location, instead of creating the new bar files in AppData on update it's correct either to continue to use the currently writable bar files in Program Files, or during update to ask user whether one wants to move current bar files from Program Files to AppData.

And this will work always - not only when launched in administrator mode, or when directory access rights have been modified.

Also, since the user and the Administrator are different accounts, it's correct by default to use different locations for their settings (AppData and Program Files), unless user during application setup didn't choose to share the settings for all accounts.

[MarcinW]

Also, since the user and the Administrator are different accounts, it's correct by default to use different locations for their settings (AppData and Program Files)

No, launching TC as elevated (= in administrator mode) does NOT use "Administrator" account - but the same user account with higher privileges.


Try the following: launch command line (cmd.exe) and use "whoami" and "set APPDATA" commands - you will see something like:

Code: Select all

C:\Users\X>whoami
compname\X

C:\Users\X>set APPDATA
APPDATA=C:\Users\X\AppData\Roaming

Now launch cmd.exe in administrator mode - you will same results.

You can see the difference when calling "whoami /all" command - when launched under elevated cmd.exe, it shows much more privileges assigned.


Regards

[DrShark]

No, launching TC as elevated (= in administrator mode) does NOT use "Administrator" account - but the same user account with higher privileges.

Still, some programs write own settings to different real file system locations under App Data if launched as normal user and as Administrator:
%userprofile%\AppData\Local\VirtualStore\
%userprofile%\AppData\Roaming\
It seems VirtualStore is used in case an app doesn't have a write access to some settings file when launched not-elevated. I think in case TC can't write to real *.bar files in %programfiles%\Total Commander\, it should then try to write to %userprofile%\AppData\Local\VirtualStore\Program Files\Total Commander\*.bar

[MVV]

VirtualStore is a special system folder that is used for redirecting write operations to protected locations for old programs that don't support elevation, and subsequent read operations use files from this folder first. TC does support elevation so its write operations are not redirected but failed.

[Dalai]

No application should ever write to VirtualStore directory by itself! The VirtualStore directory is automatically used by Windows in case

• the application is started without write access to its application directory, e.g. somewhere in %ProgramFiles%
• the application doesn't have a manifest embedded in its executable file
• the application tries to write some file to its application directory.

If all of the above conditions are true, Windows redirects the write event to the VirtualStore directory in the current user's profile, without the application knowing about it, i.e. the application still "thinks" it wrote to its application directory. In turn, read access is also redirected, so very old applications without a manifest still work, although every user of such application has his/her own settings (since the VirtualStore is user-specific).

Regards
Dalai