TC 10.x-introducted feature of (.ini-)file redirection causes FSplugins to misbehave

[Steevee]

Hi,

I'm a developer of a FSplugin and recently stumbled across a problem:
it was suddently no longer possible to view some certain files from within our FSplugin by simply pressing "F3" (View).

Debugging showed that TC uses FsGetFile() to download the file to some local directory "c:\Users\<username>\AppData\Local\Temp\_tc\" and then displays that file using its built-in Lister.
Unfortunately, although our FSplugin successfully copied that file to that local folder (by CreateFileA() and filling it with the content from our internal filesystem), it won't be there afterwards and the Lister wont find it.
Further debugging showed, that only INI-Files are affected.

It took me a looong while to finally find out that this is a side effect of a feature that was introducted in TC 10.00, stating:

For plugins in write protected directories, intercept calls to CreateFileA/W and all INI functions, and redirect write calls to %APPDATA%\GHISLER\redirect

Intended to help plugins installed in "C:\Program Files\totalcmd\plugins" (like ours) to store its configurations in user-friendly locations, this feature no longer allows file-system plugins to correctly behave for INI-Files, because it also causes redirection of files that are to be created by FsGetFile() and they will be placed in the wrong location, namely "%APPDATA%\GHISLER\redirect\C_\Users\<username>\AppData\Local\Temp\_tc\".
Consequently, the Lister won't find the file afterwards.

Our (working) mitigation strategy is now to use a ".ini~" suffix at first when placing the file in the "c:\Users\<username>\AppData\Local\Temp\_tc\" folder and afterwards renaming it.
Anyway, I think that this behaviour of TC should be fixed.

Note: tested on TC 10.52 x64, (admin-installed in C:\Program Files\totalcmd).

[petermad]

Note: tested on TC 10.52 x64

TC 10.52 is more than 1½ years old - have you tried with the current TC 11.03 ?

Have you tried using [ReplaceIniLocation] for your plugin:

[ReplaceIniLocation]
Set a different ini file location for specific plugins, via function *SetDefaultParams, parameter DefaultIniName, via line pluginfile.ext=c:\path\newinifile.ini or pluginfile.ext=c:\path\ - the plugin may ignore the name and just use the path.
pluginname.ext= New location of ini file sent to the plugin. The plugin name must be specified without path, and with extension as configured in wincmd.ini, e.g. sftpplug.wfx
Special values:
* send default value, but redirect to user profile if location not writable (default for packer, file system, and lister plugins)
- send default value, but do not redirect to user profile on fail (default for content plugins)

Introduced in TC 10.0

[ghisler(Author)]

This function was added for misbehaving plugins which ignore the "DefaultIniName" sent to them via FsSetDefaultParams. The documentation says:
"It's recommended to store the plugin data in this file or at least in this directory, because the plugin directory or the Windows directory may not be writable!"
So when a plugin ignores this and is trying to write to an ini file in its own directory, this will fail if the plugin is installed under "Program Files" or some other write protected folder.

Therefore Total Commander does the following when an ini file can't be created there:
1. It checks if there is already a copy of the file under %APPDATA%\GHISLER\redirect\path\to\original\ini
2a. If there is one, use that instead
2b. If there isn't, copy any existing ini file from the write only location to the new one, and open it.

If you don't want that mechanism, then you can either
- follow the rules and put your ini in the same directory as reported via DefaultIniName. If the file doesn't exist yet, copy it from a template file in your plugin directory.
or
- use a different extension than .ini to store your data, and don't use *PrivateProfileString functions because they all get redirected too.

[Dalai]

2ghisler(Author)
As far as I understand it it's not about plugin settings in this case but INI files within the WFX plugin.

[Steevee]

2ghisler(Author)
As far as I understand it it's not about plugin settings in this case but INI files within the WFX plugin.

Yes! That's the point.
When TC uses FsGetFile() to download a file from our filesystem plugin that is incidentally an INI-FIle, it will be affected by the file redirection.

The LocalName where our FSplugin has to download the file to is defined by TC itself when calling FsGetFile(), so in order to fix this problem, one possible solution could be to disable INI-File redirection for that specific filename when calling FsGetFile().
See function declaration of FsGetFile():

Code: Select all

int __stdcall FsGetFile(char* RemoteName,char* LocalName,int CopyFlags,RemoteInfoStruct* ri)

[Steevee]

(...) TC 10.52 is more than 1½ years old - have you tried with the current TC 11.03 ? (...)

Just as a side note: Yes, the problem/bug still exists unchanged in TC 11.03.

[Dalai]

2Steevee
Out of curiosity: Can you reproduce the issue with the SFTP plugin while transferring files or view them via F3? I tried it with that plugin but the plugin settings files are writable, so I can't test it properly. It might give Christian additional incentive to work on this problem.

[Steevee]

2Steevee Out of curiosity: Can you reproduce the issue with the SFTP plugin (...) ?

No, I can't! Viewing *.ini Files from some SFTP server by pressing F3 works and that made me curios, too!

But after some long additional debugging sessions I believe that I finally found the answer:

• the SFTP plugin calls CreateFileW() with open mode OPEN_ALWAYS causing the file access to not being redirected by TC

• our FSplugin calls CreateFileW() with open mode TRUNCATE_EXISTING causing the file access to instead become redirected by TC

@ghisler(Author): does that makes sense for you?

EDIT:
Our FSplugin uses TRUNCATE_EXISTING at first to check whether there is already a file that needs to be overwritten and truncate it in that case. If that fails (in case there is no such file), a second CreateFile() call is performend with open mode CREATE_NEW.
So, normally, when TC calls FsGetFile() to download a file from our FSplugin, the open mode TRUNCATE_EXISTING should fail (because there is usually no such local file) and the second call should then create a new file in the correct location.
But for some reason, TC creates an empty file at the redirected location for open mode TRUNCATE_EXISTING, although there is no such file in the original location! This causes our FSplugin to write the contents to the wrong (redirected) location.
Note that this behaviour of CreateFile() is clrearly against the specification which states "TRUNCATE_EXISTING: Opens a file and truncates it so that its size is zero bytes, only if it exists.", see Documentation of CreateFile function.

So, I think that this is the actual bug in TC's implementation of redirection! But in addition, I think it is still a good idea to switch off TC's redirection at all in case the filename of CreateFile() matches LocalName in FsGetFile().

[ghisler(Author)]

So, I think that this is the actual bug in TC's implementation of redirection! But in addition, I think it is still a good idea to switch off TC's redirection at all in case the filename of CreateFile() matches LocalName in FsGetFile().

I agree, I will add this.

[JOUBE]

Thanks to Steevee and to ghisler(Author) for this dialogue. It was fun and interesting to read.

[Steevee]

I agree, I will add this.

Btw. thank you for all your continued work on Total Commander!
Today, I'd feel naked and helpless on Windows without Total Commander. For me it's the one and only truly usable File Explorer for Windows!