`Move` (F6) within the same volume should always be completed instantly

[jb]

Sometimes it happens that a `Move` (F6) operation within the same volume is not completed instantly.
Instead TC starts copying and deleting like mad as if source and destination were on different volumes.
This seems to happen when the source is locked (partially), for example by TortoiseGit.
It would help if TC could inform the user in such cases before doing needless work.

[Dalai]

This is a long-standing issue and I think I made a suggestion about it many years ago that TC should show a confirmation where the user can choose whether to copy+delete the file(s) or cancel the operation. Can't find it right now, only my little rant about the annoyance that comes with it : https://www.ghisler.ch/board/viewtopic.php?p=332199#p332199

Regards
Dalai

[petermad]

If you have "Operation" -> "File comments" -> "Copy comments with files" that could account for some of the activity.

[jb]

... Can't find it right now, only my little rant about the annoyance that comes with it : https://www.ghisler.ch/board/viewtopic.php?p=332199#p332199

Indeed I'm getting annoyed about this behavior every now and then since years. After all it would be easier to accept, when somebody could explain, why it is hard to change. Is it caused by the Win32 API in the end? Seems unlikely to me.

[jb]

If you have "Operation" -> "File comments" -> "Copy comments with files" that could account for some of the activity.

This option is disabled in my configuration. However, it should not matter when you move a directory within the same volume.

[funkymonk]

Yes, it's truly annoying.
Sometimes it helps (or seems to help) to restart TC...

[ghisler(Author)]

Sometimes it happens that a `Move` (F6) operation within the same volume is not completed instantly.

This should actually be fixed since Total Commander 11 beta 1: It happened when you confirmed the F6 dialog while TC was still counting files. That prevented the direct move of the directory. The beta now stops the counting thread and wait until it's closed before it tries to move the directory, so the error should no longer occur.

[jb]

This should actually be fixed since Total Commander 11 beta 1: It happened when you confirmed the F6 dialog while TC was still counting files. That prevented the direct move of the directory. The beta now stops the counting thread and wait until it's closed before it tries to move the directory, so the error should no longer occur.

What is supposed to happen after this correction when the source directory is partially locked?

[ghisler(Author)]

If something else locks the directory, TC will still copy the directory and then move the files and directories inside of it one by one.
My fix only addresses the case where TC itself was locking the directory.

[JOUBE]

Sometimes it happens that a `Move` (F6) operation within the same volume is not completed instantly.

This should actually be fixed since Total Commander 11 beta 1: It happened when you confirmed the F6 dialog while TC was still counting files. That prevented the direct move of the directory. The beta now stops the counting thread and wait until it's closed before it tries to move the directory, so the error should no longer occur.

This is a really important and useful improvement. Because that was really annoying: forgot to wait until the counting thread was over and it started miserably. *) Thanks for that!

Applications also often block a move and prevent a simple reassignment of a directory that was started from inside Tc while Tc was in this directory. For example the browser startet with an url file within Tc. (Lockhunter: the Browser (not the Tc itself) locks the folder).

Joube

*) Stop moving immediately, move back what you started, f6 again, wait this time until counting thread finished: move in tenths of a second...

[jb]

If something else locks the directory, TC will still copy the directory and then move the files and directories inside of it one by one.
My fix only addresses the case where TC itself was locking the directory.

Probably the fixed case occurred more frequently but the current behavior is very annoying regardless of the reason.
Would it be hard to fix also the other case and if yes why?
Note that my initial post addressed the other case (external lock) and suggested to give the user a choice before racing ahead.
An extra bonus would be to tell the user which processes are locking the directory to be moved.

[AntonyD]

An extra bonus would be to tell the user which processes are locking the directory to be moved.

Which is MOST DESIRABLE in this case, IMHO... and quite doable...

[Hacker]

So, basically, implement the basic LockHunter functionality (list locking processes) in TC?

Roman

[AntonyD]

So, basically, implement the basic LockHunter functionality (list locking processes) in TC?

yep.
Have we got the basic functionality of the video-audio player in Lister ?

[ghisler(Author)]

So, basically, implement the basic LockHunter functionality (list locking processes) in TC?

There is (to my knowledge) no official function to get this information, it's using undocumented Windows functions.