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:
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\".For plugins in write protected directories, intercept calls to CreateFileA/W and all INI functions, and redirect write calls to %APPDATA%\GHISLER\redirect
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).