[TC 8.0 B22 x64] FS Plugin detection problems (continued)

[EricB]

When checking fix for FS plugin detection in TC 8.0 B22 x64, some erroneous behaviour was found. See also related topic for TC 8.0 x32, which was fixed in B22: http://www.ghisler.ch/board/viewtopic.php?p=243325#243325.

Setup clarification: x32/x64 both portable in same folder, sharing wincmd.ini. All paths (plugins etc) use %COMMANDER_PATH% to remain portable.

Installing an FS plugin in x64 (in this case Virtual Panel) which already exists for x32, the overwrite dialog is shown, but shows hard path to plugin instead of path including environment variable %COMMANDER_PATH%. When confirming the overwrite this hard path is also put into the FileSystemPlugins section, overwriting the existing path.

Afterwards a second dialog is shown which states that an existing plugin was found with the same name but in a different directory, do you want to remove it?

It seems that for x64 the plugin path is resolved, but then compared to the unresolved path (which are different of course).

IMO the %COMMANDER_PATH% variable should never be resolved in this case.

Regards, EricB

Edit: small corrections (thx Petermad)

[petermad]

Setup clarification: x32/x86 both portable in same folder

I guess you mean x64/x86 both portable in same folder?

When removing it, the plugin entry for x32 is

is what? - something seems to be missing in this sentence.

[EricB]

Thx Petermad, updated first post for clarity.

Regards, EricB

[ghisler(Author)]

Sorry, I do not understand your report. Do you mean that there is a bug in 64-bit but not in 32-bit?

[EricB]

Christian,

In my first post of this thread I linked to a similar problem which was fixed in Beta 22 but only confirmed (by me) for x32. I could not test x64 at the time, and when doing this today, I found x64 to be faulty. I decided not to follow up on the older thread because it was already moved to the TC Fixed bugs section, but to create this new one instead. I put x64 in the topic title to indicate it is x64 only. The x32 version has no problems.

Your actual fix is '29/02/2012 Fixed: Installing a plugin a second time didn't find the previous installation if the existing plugin path contained an environment variable (32/64)'

I hope this clarifies matters.

Regards, EricB

[ghisler(Author)]

Cannot reproduce, I just tried it - I'm getting the same dialog also in the 64-bit version with your ini files:

---------------------------
VirtualPanel.wfx
---------------------------
A plugin with this name is already installed in the following directory:

%COMMANDER_PATH%\Plugins\wfx\VirtualPanel\

Do you want to overwrite it?
Choose 'No' to select a different location.
---------------------------
Ja Nein Abbrechen
---------------------------

I started TC from D:\tc8\TOTALCMD64.EXE (the linked dir) and from D:\document\dropbox\tc8\TOTALCMD64.EXE (the real location), same effect.

Here are some values of ini entries:
wincmd.ini
[Configuration]
pluginbasedir=%COMMANDER_PATH%\Plugins

Settings\Plugins.ini
[FileSystemPlugins]
Virtual Panel=%COMMANDER_PATH%\Plugins\wfx\VirtualPanel\VirtualPanel.wfx

Any ideas?

[EricB]

Odd, for me it happened all the time. I have currently no access to the x64 machine, so I'll have to postpone further investigation till tomorrow. I'll also post some screenshots if necessary.

Regards, EricB

[ghisler(Author)]

Could you check the values of the above ini values on 64-bit, please? Maybe they differ from mine?

Edit:
I remember that you sent me one ini file where the plugin path for VirtualPanel.wfx was an absolute path (no env. var.).

I even tried to delete the VirtualPanel.wfx64 before my test, but it worked fine too...

[EricB]

Christian,

My ini values are the same. Currently all my FS plugins use the environment variable.
I've done experiments yesterday with removing complete plugin reference and folder. On first install the proposed path is correctly shown with environment variable in it and also correctly written in plugins.ini. On second install I get the hard path, which is then also written in the plugins.ini. And I get the second dialog which states that an existing plugin was found with the same name but in a different directory, do you want to remove it?

I'll try to compile a more reproducible scenario tomorrow.

Regards, EricB

[ghisler(Author)]

Ah, that's a different scenario - I just tried to re-install a plugin which was already there, not install the same plugin twice within the same session - that seems to have the described effect. I will check it.

[EricB]

When I start TC 8.0 B22 x64 anew, and I reinstall an existing plugin (Virtual Panel, but same for your WPDPlug) I see the same behaviour:

In the overwrite confirmation dialog the hard path to existing plugin is shown. After confirming the overwrite the File Systems plugins panel is shown and the message about 'existing plugin was found with the same name but in a different directory, do you want to remove it?'.

- The FS plugins panel still shows the original plugin path with environment variable (I have to move the dialog box to see this).
- This is also still the case in plugins.ini, but FileSystemPlugins64 section is removed.
- When confirming existing plugin removal, the hard path is shown in the FS plugins panel, and the line is shifted to the end of the list. Plugins.ini still contains the original line unshifted with environment variable
- After using OK on the FS plugins panel the hard path is written to plugins.ini as last line. FileSystemPlugins64 section is added again.

Hope this helps to get more insight.

Regards, EricB

[EricB]

Just tested using TC 8.0 Beta 23 x64:

07/03/2012 Fixed: Installing a plugin twice in the same session didn't find the previous installation if the existing plugin path contained an environment variable (64)

- No hard path is shown in overwrite dialog, path with environment variable is now correctly shown
- FS plugins panel shows correct path with environment variable
- No 'existing plugin was found with same name etc' dialog is shown
- Path with environment variable is correctly written to FileSystemPlugins section of plugins.ini

So the issue seems to be fixed. Thx!

Regards, EricB

[ghisler(Author)]

Ah, finally - thanks for your help fixing this problem!