New environment for wcx_ftp.ini

[george60120]

We have

• %Commander_Drive%
• %Commander_Path%
• %Commander_EXE%
• %Commander_INI%

Is there any chance to provide new environment for wcx_ftp.ini in TC 8?

I searched the forum and found that it was requested before here ghisler.ch /board / viewtopic.php?t=11102

I need this variable because i usually run more than TC instance using /i and /f param, these instances share some settings like main toolbar, it is easy to define button to edit current wincmd.ini using %Commander_INI% and this button work nice for all instances but it is difficult to create one button to edit current wcx_ftp.ini.

I hope to see %Commander_FTPINI% as soon as possible.

[petermad]

Support++

[ts4242]

Support ++++++++++++++++++++++++

[mame]

I like! +++++++++
(Was looking for 'Like' button, can we have it here in this forum?)

[george60120]

@Ghisler

Please let's hear (good news) from you.

[ghisler(Author)]

There is no reason for programs to access the wcx_ftp.ini, except perhaps for stealing unencrypted passwords...

[Flint]

There is no reason for programs to access the wcx_ftp.ini, except perhaps for stealing unencrypted passwords...

Ultra TC Editors disagree with you.

[ts4242]

There is no reason for programs to access the wcx_ftp.ini, except perhaps for stealing unencrypted passwords...

Before you decide take the following points into your account:

* Protecting Wcx_ftp.ini from stealing passwords is user responsibility not TC.

* It is not difficult for any SpyWare to know the place of Wcx_ftp.ini by looking in the registry, TC folder or even get it from TC command line param /f e.g. Process Explorer show TC command line in its property dialog. (Process Explorer is not spyware, i just give an example of application that can get Wcx_ftp.ini from the command line)

* Wcx_ftp.ini includes many settings which cannot set via TC configuration dialog therefore we are forced to edit it manually.

* TC has cm_ConfigChangeIniFiles to edit current Wcx_ftp.ini but it is always open it with Notepad which is bad choice for advanced user who need to edit it with powerful text editor or powerful tool like Ultra TC Configuration Editor

* As george60120 said it will be easy to use one command button to edit current Wcx_ftp.ini with a user-defined editor from any TC instance.

So, please complete TC's environment variables set.

[petermad]

* TC has cm_ConfigChangeIniFiles to edit current Wcx_ftp.ini but it is always open it with Notepad which is bad choice for advanced user who need to edit it with powerful text editor or powerful tool like Ultra TC Configuration Editor Smile

* As george60120 said it will be easy to use one command button to edit current Wcx_ftp.ini with a user-defined editor from any TC instance.

So, please complete TC's environment variables set.

I totally agree.

[mame]

I have to admit, I wasn't thinking about security at first, only convenience. After reading Ghisler's answer, I think he is correct. Sorry.

There is no reason for programs to access the wcx_ftp.ini, except perhaps for stealing unencrypted passwords...

Because anything being launched from TC will have the environment available to it (making the target clear), so the risk is there, even minimal.

[Flint]

Because anything being launched from TC will have the environment available to it (making the target clear), so the risk is there, even minimal.

I would disagree.
First, there is no problem to find out which wcx_ftp.ini is used by TC, and there are already troyans that steal passwords from this file, and they don't need the variable for their work. So, implementing this variable will only make an easier way to do something that is done already, and it will not make matters worse.
Second, the variable is defined only within TC itself and all applications started from it. Since malicious software mostly come from the Internet (browsers, E-mail clients), or from USB flash autorun.inf, all these programs just will not see the new environment variable, because they are not started from TC or any of its decendants. Of course, there is still possibility that the browser was started from TC, or that the user started a troyan from TC, but these situations are quite rare, and even when they take place, see the first argument: troyans actually don't need the variable, they can do without it.


One more argument for the new variable: Ghisler constantly refuses to change the default editor in cm_ConfigChangeIniFiles. Currently, it is impossible to simulate its behaviour with a EM-command. If the new variable was implemented, one could just write:

Code: Select all

my_editor.exe %COMMANDER_INI% %COMMANDER_FTP_INI%

and so implement a worthy alternative for the command.

[george60120]

There is no reason for programs to access the wcx_ftp.ini, except perhaps for stealing unencrypted passwords...

You must not care about careless users, you introduced the possibility to protect connections with master password, therefore if the user didn't encrypt his valuable connections then he must not blame anyone but himself.

@Ghisler
Go ahead and give us the new year gift

[karlchen]

Hello, Flint.

First, let me make clear that I do like the suggestion of having a variable like %COMMANDER_FTP_INI%. I agree, too, that it is hard to imagine how this variable would help malicious software to perform tasks that cannot be achieved today, too.

Irrespective of this, I am not quite sure that this statement really applies:

[...] cm_ConfigChangeIniFiles. Currently, it is impossible to simulate its behaviour with a EM-command.

I suspect that the following em-command achieves this goal. At least it does so here:

[em_editinis2]
button="%COMMANDER_PATH%\..\ProgrammersNotepad\pn.exe"
cmd=""%COMMANDER_PATH%\..\ProgrammersNotepad\pn.exe" "%COMMANDER_INI%\..\usercmd.ini" "%COMMANDER_INI%\..\wcx_ftp.ini" "%COMMANDER_INI%""
path=%COMMANDER_PATH%
iconic=1

And I would be amazed if other users did not use similar em-commands in order to "Change Settings Files Directly". The limitation of this cm_ConfigChangeIniFiles fork is that it assumes that all 3 INI files are located in the same folder, which will often be true, but which need not be true.

Kind regards,
Karl

[Flint]

karlchen
Hm… I always was of the opinion that appending .. to a file path would not work. I tested now and admit that I was wrong. I cannot tell why I thought so, maybe because it did not work in some earlier Windows versions, or because it is not allowed in Linux (in Linux it's definitely not allowed, I just checked it).

OK, one argument less, but all others are still valid.

[petermad]

The limitation of this cm_ConfigChangeIniFiles fork is that it assumes that all 3 INI files are located in the same folder, which will often be true, but which need not be true.

Another limitation is that it assumes that the name of the ftp ini file is wcx_ftp.ini which it also isn't necessarily, if TC is started with the /f= parameter.

So I still support the request for this variable.

There is a difference between the need for an env. var. for wincmd.ini and wcx_ftp.ini compared to the other ini files - which is that the names and location of these two files can be changed at commandline, and hence might vary for each running instance of TC.

The names of usercmd.ini, pkplugin.ini, lsplugin.ini, fsplugin.ini and contplug.ini are all fixed, and the path is always the same as for the current main ini file, so the path for those 5 files can be obtained by using %COMMANDER_PATH%\..\ - so there is no need for further of these env. variables, just one for the current ftp ini file.