-Cannot delete folder after open configuration files

JFierce7 · Post by *JFierce7 » 2014-03-01, 16:21 UTC

After opening configuration files for direct editing, what ever folder had been open in the currently chosen side at that moment of time cannot be deleted until both instances of notepad with configuration files have been closed.

Sir_SiLvA · Post by *Sir_SiLvA » 2014-03-01, 16:33 UTC

ANd this is NOT a TC bug but Windows that locks the folders....

JFierce7 · Post by *JFierce7 » 2014-03-01, 16:37 UTC

Sir_SiLvA wrote:this is NOT a TC bug

Sure it is. TC needs to set a certain working (or current) directory when opening notepad as a process. It could use the folder where wincmd.ini resides or the temp folder.

Horst.Epp · Post by *Horst.Epp » 2014-03-01, 17:07 UTC

JFierce7 wrote:
Sir_SiLvA wrote:this is NOT a TC bug
Sure it is. TC needs to set a certain working (or current) directory when opening notepad as a process. It could use the folder where wincmd.ini resides or the temp folder.

Sorry but that is not what I normaly want.
TC should not change the current working dir just because I'm starting some program. I may want to work exactly on that current folder within the editor.
The problem you are describing will happen once in a million I guess.
Any you can easy avoid it by changing the dir to whatever you want before you make config changes.

JFierce7 · Post by *JFierce7 » 2014-03-01, 17:31 UTC

Horst.Epp wrote:Sorry but that is not what I normaly want.
TC should not change the current working dir just because I'm starting some program. I may want to work exactly on that current folder within the editor.

I'm talking about the "current working directory" of the notepad processes that have opened the configuration files wincmd.ini and wcx_ftp.ini. IMO, one would expect, that its current directory is the directory of the configuration files. I would think its rather unusual to use these editor instances for other files.

Of course, the current directory of TC or any other editor window should not be changed.

Dalai · Post by *Dalai » 2014-03-01, 19:39 UTC

Not it's not a TC bug, it is working as designed. The current directory is always used as working dir for newly created processes (and it is good this way).

Regards
Dalai

Post by *petermad » 2014-03-01, 19:40 UTC

The same thing happens if you open a file for editing in Notepad from Windows Explorer - in that case you can not delete the directory containing the file, neither from Explorer, nor from TC

JFierce7 · Post by *JFierce7 » 2014-03-01, 20:47 UTC

Dalai wrote:Not it's not a TC bug, it is working as designed. The current directory is always used as working dir for newly created processes (and it is good this way).

Editing configuration files (initiated via the corresponding menu item) is not the "usual" start of a new process. It's a special function used for exactly that: editing of config. Locking some unrelated folder is a bug.

petermad wrote:The same thing happens if you open a file for editing in Notepad from Windows Explorer - in that case you can not delete the directory containing the file

Of course. But I don't want to delete the directory where wincmd.ini is in. The problem is that any folder that just happens to be open in TC when you start editing wincmd.ini via menu cannot be deleted.

Post by *petermad » 2014-03-01, 20:56 UTC

The problem is that any folder that just happens to be open in TC when you start editing wincmd.ini via menu cannot be deleted.

It is not TC that locks the folder it is Notepad - just try it with a program like Unlocker ( http://www.emptyloop.com/unlocker/ ) - it will show you that it is Notepad that is locking the directory.

MarcinW · Post by *MarcinW » 2014-03-01, 21:13 UTC

Dalai wrote:Not it's not a TC bug, it is working as designed. The current directory is always used as working dir for newly created processes (and it is good this way).

I can't agree. All API functions (CreateProcess, ShellExecute and ShellExecuteEx) provide a way to set the starting directory for the newly created process.

I can confirm the problem, that JFierce7 reported.

When I go to "c:\test" directory in TC and use Configuration -> Change Settings Files Directly menu, I can see in the Sysinternals Process Explorer:

Code: Select all

Path:
    C:\WINDOWS\system32\notepad.exe
Command line:
    notepad.exe C:\Documents and Settings\X\Application Data\GHISLER\wincmd.ini
Current directory:
    c:\test\

So Notepad blocks "c:\test" directory and this directory can't be deleted in TC.

Current directory should be set to the directory of wincmd.ini:

Code: Select all

Current directory:
    C:\Documents and Settings\X\Application Data\GHISLER\

Same situation is with wcx_ftp.ini.

Regards

Dalai · Post by *Dalai » 2014-03-01, 21:23 UTC

MarcinW wrote:
Dalai wrote:Not it's not a TC bug, it is working as designed. The current directory is always used as working dir for newly created processes (and it is good this way).
I can't agree. All API functions (CreateProcess, ShellExecute and ShellExecuteEx) provide a way to set the starting directory for the newly created process.

I meant TC is always using the current folder as working dir. What function TC uses (or doesn't use) doesn't matter in this regard.

Regards
Dalai

Post by *petermad » 2014-03-01, 22:33 UTC

Current directory should be set to the directory of wincmd.ini:

This is not a bug but a request, that you could make a topic for in TC suggestions (English) and it should rather be set to the directory of %COMMANDER_INI% wich might not be wincmd.ini
.

JFierce7 · Post by *JFierce7 » 2014-03-01, 23:03 UTC

petermad wrote:It is not TC that locks the folder it is Notepad - just try it with a program like Unlocker ( http://www.emptyloop.com/unlocker/ ) - it will show you that it is Notepad that is locking the directory.

If TC would have an internal editor for wincmd.ini which would lock what ever directory is currently open and which is in no kind related to any config file, would you say this is another situation?

TC makes use of notepad for some internal function. It should avoid any side-effects (which even may influence third party programs). I would treat any such side-effect as bug.

Sir_SiLvA · Post by *Sir_SiLvA » 2014-03-01, 23:30 UTC

JFierce7 wrote:
petermad wrote:It is not TC that locks the folder it is Notepad - just try it with a program like Unlocker ( http://www.emptyloop.com/unlocker/ ) - it will show you that it is Notepad that is locking the directory.
If TC would have an internal editor for wincmd.ini which would lock what ever directory is currently open and which is in no kind related to any config file, would you say this is another situation?

TC makes use of notepad for some internal function. It should avoid any side-effects (which even may influence third party programs). I would treat any such side-effect as bug.

If you dont like it redirect your complains to www.microsoft.com please as they create your os and its an os
security feature

JFierce7 · Post by *JFierce7 » 2014-03-02, 08:52 UTC

Sir_SiLvA wrote:If you dont like it redirect your complains to www.microsoft.com please as they create your os and its an os
security feature

Sorry - do you feel personally insulted? I see your smiley, but I don't understand your reasoning. Why not keep it technical?

Is it so hard to understand? You say it's a "security feature". That's okay for me. However, the "security feature" is not correctly used. It's simply the wrong directory that is locked because the call to notepad misses some parameter.