Bug: One instance of TC prevents another to ren/del a folder

[katatonic]

If a folder is opened in a panel of one instance of TC (instance 1), the same folder cannot be renamed or deleted by another instance of TC (inst. 2), the error is "Error: Cannot read xxxx".
A much better behaviour would be to allow the renaming/deletion of the folder by inst. 2 and changing to the root of the drive or the parent folder in inst. 1.
As a whole, TC should not hold open read handles to folders, thus preventing Windows or other instances of TC from modifying these folders.

At least, if this is not possible, the error should me more informative.

[SanskritFritz]

As a whole, TC should not hold open read handles to folders

IMHO this is impossible, because Windows requires it.

At least, if this is not possible, the error should me more informative

That is possible. And desireable.

[IGL]

In my system (on Win XP) TC 6.02 sometimes says:
Cannot DELETE folder and somtimes allows to delete it and the first copy of TC automatically goes to the upper dir.
But such error "Cannot delete folder" may occur alo with other programs that just keep the folder open - it does not only occure with TC.

[katatonic]

Yes, other programs can also prevent the deletion of a folder or a file they have opened, that is normal.
But when TC is the only program, that has opened a folder, TC should not complain about not being able to delete the folder.
(even if one instance of TC has opened the folder and another one is trying to delete it).

I suppose that normally when opening a folder in the panel, TC should read the contents, display it, and then close the file handle, used to read the contents so that other programs may modify (rename/delete) the folder.
However, for some reason TC seems to keep the file handle open. Maybe it is used to reread the contents on a regular period (for synchronization purposes) or for some other reason, I don't know. Or it might just be a bug that the file handle is not always closed. But the side effect is quite unpleasant.

It is interesting what Mr. Ghisler would say on the problem

[ghisler(Author)]

TC does not hold open a read handle of the folder, but it uses SetCurrentDirectory() to set the current dir to that folder. Windows does prevent the deletion of a dir which is the current dir in ANY running program.

[katatonic]

TC does not hold open a read handle of the folder, but it uses SetCurrentDirectory() to set the current dir to that folder. Windows does prevent the deletion of a dir which is the current dir in ANY running program.

Ok, I'm not a C/WindowsAPI programmer so forgive me if I'm totally wrong, but:
Is it really necessary to have the current folder set as current directory - probably this could be done only before operations which require it - like executing stuff from the command line or you know what else
But is it really needed for the most common file operations like copying, moving and deleting?

Again, I might be completely wrong in what I'm saying, sorry if this is the case

[Sheepdog]

TC does not hold open a read handle of the folder, but it uses SetCurrentDirectory() to set the current dir to that folder. Windows does prevent the deletion of a dir which is the current dir in ANY running program.

I made a few tests. If the concerned folder is in an active Tab of the second TC instance you couldn't rename/delete it. If the Tab is inactive you could. And if you activate it, TC switches to root-level.
If you open the folder with explorer you can delete/rename it with TC. When you reactivate the explorer it says that the folder applys to a path that is not available. When you reread the directorytree you can access the folder (or it is disappeared ).

[JohnFredC]

I have noticed this "inability to rename/delete a folder" issue many times. Very aggravating.

There is a little utility called "Who Lock Me?" which tells me that TC "owns" the problem folder. In many cases I have to completely close TC in order to rename that folder.

Sometimes there is a second vestigial (and invisible to the GUI) copy of TC that appears in the Taskman Processes list and that apparently owns the folder. If I terminate that copy using TaskMan then after that usually the folder becomes available for renaming.

[Clo]

2JohnFredC

There is a little utility called "Who Lock Me?" which tells me that TC "owns" the problem folder

Hi !
• Please, could you give us a link to get that utility ?
Though I don't use neither several instances of TC, nor the tabs generally, it should be useful for other users who suffer that issue.

Regards,
Claude
clo

[Leif]

Google gave: http://www.dr-hoiby.com/tools.html

[Clo]

2Leif
 Hi Leif !
• Thanks, I'll have a look there!
EDIT : well, I saw... that it doesn't work under Win 9x and ME.
• The equivalent for Win 9x should be nice to get!

Merry Easter,
Claude
Clo

[Sheepdog]

2JohnFredC

There is a little utility called "Who Lock Me?" which tells me that TC "owns" the problem folder

Hi !
• Please, could you give us a link to get that utility ?

Hi Claude,

thats exactly what I thought and wanted JohnFred ask for. Stupidly I didn't read your posting and posted my request. But for I'm a 'Senior Member' I did know how to delete my posting

It's nice to know you have a look at the forum and take the interests of the other members like yours.

thanks

sheepdog

[JohnFredC]

This is where I got WhoLockMe (no spaces!!)

http://www.dr-hoiby.com/WhoLockMe/

[SanskritFritz]

2Clo
Quote from the homepage mentioned above:
"This freeware is an beta version, it Doesn't work on Win9x or WinMe.. "

[Clo]

2SanskritFritz
  Hi !
• It's what I meant !
* I went on that page and saw that. So, I didn't download and install that utility.
  K R
Claude
Clo