Total Commander

Currently Total Commander installer asks to close currently running TC instances before coutinuation of update process, and even itself offers an option to try to close such instances (usually installer closes main TC instances pretty fine, but it's not so good for closing separate proccesses of Find Files etc.).

However, at the time of update I sometimes have many windows of Total Commander tools as separate process running (mainly Find Files with search results or Lister). To finish the update, I have to close all these windows, and if I want to continie the work with that Find Files results and Lister documents, before closing I have to save search results lists and the paths to documents opened in Lister. Then after update I need to manually reopen each separate process instance.

Please correct me if I'm wrong, but I guess if to overwrite Total Commander's EXE it shouldn't hurt already running tools like Lister or Find Files launched previously as separate TC processes. It true, it would be nice if the installer could offer an option to close only TC processes with main TC window, but leave its tools in separate processes running while updating the EXE of Total Commander.

TC has only one main EXE file and all tools are contained within that file, be it Find Files, Lister, Sync tool, MRT and so on. You can see that yourself in Task Manager that there are more totalcmd.exe or totalcmd64.exe processes running than there are TC main windows. In other words: What you suggest is not possible.

Regards
Dalai

Dalai wrote: ↑2021-04-09, 15:35 UTC TC has only one main EXE file and all tools are contained within that file, be it Find Files, Lister, Sync tool, MRT and so on. You can see that yourself in Task Manager that there are more totalcmd.exe or totalcmd64.exe processes running than there are TC main windows. In other words: What you suggest is not possible.

Yes, they're in one EXE. What I mean is, if TC's installer will unlock TC's EXE on disk from proccesses in RAM, then overwrite it with new version, the processes of old EXE should still continue to run in RAM more or less fine.

DrShark wrote: ↑2021-04-09, 15:59 UTC

Dalai wrote: ↑2021-04-09, 15:35 UTC TC has only one main EXE file and all tools are contained within that file, be it Find Files, Lister, Sync tool, MRT and so on. You can see that yourself in Task Manager that there are more totalcmd.exe or totalcmd64.exe processes running than there are TC main windows. In other words: What you suggest is not possible.

Yes, they're in one EXE. What I mean is, if TC's installer will unlock TC's EXE on disk from proccesses in RAM, then overwrite it with new version, the processes of old EXE should still continue to run in RAM more or less fine.

Sorry but even it would be possible I find it a strange idea to update a tool while components of it are still running.
Some of the processes even may have DLLs loaded which the installer has to replace.
As a normal user I would expect the installer to close all TC related processes and nothing less.

Horst.Epp wrote: ↑2021-04-09, 16:10 UTCSorry but even it would be possible I find it a strange idea to update a tool while components of it are still running.
As a normal user I would expect the installer to close all TC related processes and nothing less.

I agree it's a bit strange, but unfortunatley unlike modern web browsers which can restore the working state of previous session after the update, too much of manual work is needed to achieve the same for TC, so suggested way of upgrade would be less painful.

DrShark wrote: ↑2021-04-09, 15:59 UTCWhat I mean is, if TC's installer will unlock TC's EXE on disk from proccesses in RAM, then overwrite it with new version, the processes of old EXE should still continue to run in RAM more or less fine.

Unlocking files that are in use by running processes will lead to a crash or unexpected behavior of that process eventually. On Windows it's not possible to update/change files which are in use. Not sure if it's due to the OS itself or the file-system. On Linux it's possible to do such a thing, but that has its own caveats (or even pitfalls).

Even if TC was compiled with the flags IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP and IMAGE_FILE_NET_RUN_FROM_SWAP (which it is not) the file would probably still be locked and not overwritable. Though I'm not sure about this because I haven't tested this.

Regards
Dalai

Dalai wrote: ↑2021-04-09, 16:41 UTCOn Windows it's not possible to update/change files which are in use.

You can rename files which are in use.

Usher wrote: ↑2021-04-09, 21:48 UTC

Dalai wrote: ↑2021-04-09, 16:41 UTCOn Windows it's not possible to update/change files which are in use.

You can rename files which are in use.

That's true, but I meant the file contents. Maybe I should've been more clear on that.

Dalai wrote: ↑2021-04-09, 16:41 UTCUnlocking files that are in use by running processes will lead to a crash or unexpected behavior of that process eventually.

Since for tools that are supposed to stay alive I don't use much of functionality (I mainy use Feed to lisbox for Find Files, and just switch to Lister instances to see opened files content) a some possibility of their eventual crash would be OK for me.

Usher wrote: ↑2021-04-09, 21:48 UTCYou can rename files which are in use.

Yes, TC's installer can rename TC EXE files which are in use and send to Windows a delete call for renamed EXE so when all handles of that EXE will be closed the Windows itself will delete it (or installer/Windows can mark it to be deleted after reboot). With this solution, there is no need for installer to unlock (close handles) of renamed EXE, so it's much less possible that the processes of old exe will eventually crash.
It'll be fine if TC's installer will offer such kind of update only is started with some specific command line switch.

Perhaps it would be a good idea to update TC only when it can be closed.

Roman

DrShark wrote: ↑2021-04-10, 05:38 UTCSince for tools that are supposed to stay alive I don't use much of functionality (I mainy use Feed to lisbox for Find Files, and just switch to Lister instances to see opened files content) a some possibility of their eventual crash would be OK for me.

Are you sure? Keep in mind that Windows may swap parts of EXE files out to make room for more important things. I'll give an example: Say there are several separate TC processes in the background. Now you open some memory-intensive program that causes Windows to "kick" said background processes from RAM. Some time later you decide to go back to one of the TC processes. To be able to correctly show the window associated with this process, it probably needs to be swapped back. But since its lock on the file is gone, it can't retrieve the information it needs and will most likely crash. In the end, you can't interact with such process anymore, and there would be no clue as to why this process crashed, and the user might see it as TC's fault - which it would be in an indirect way. Somehow I doubt Ghisler is willing to go this route.

Yes, TC's installer can rename TC EXE files which are in use and send to Windows a delete call for renamed EXE so when all handles of that EXE will be closed the Windows itself will delete it (or installer/Windows can mark it to be deleted after reboot). With this solution, there is no need for installer to unlock (close handles) of renamed EXE, so it's much less possible that the processes of old exe will eventually crash.

And now imagine several subsequent updates are made without closing the separate instances. How many totalcmd*.exe files is the installer supposed to make this way?

Hacker wrote: ↑2021-04-10, 10:01 UTCPerhaps it would be a good idea to update TC only when it can be closed.

Isn't this the way it is now? Installer won't continue if it can't close all running TC instances, does it?

Regards
Dalai

DrShark wrote: ↑2021-04-10, 05:38 UTC Yes, TC's installer can rename TC EXE files which are in use and send to Windows a delete call for renamed EXE

It's not enough. As you know, there may be other files involved - TC dlls, plugins or other files called by plugins. Some of them are out of TC control, so such an approach is NOT safe.

DrShark wrote: ↑2021-04-10, 05:38 UTCIt'll be fine if TC's installer will offer such kind of update only is started with some specific command line switch.

For me it's a waste of time. Users don't reinstall programs everyday, such a feature may be useful only for beta tests. Even in that case you don't need to install a new version immediately, I think.

Usher wrote: ↑2021-04-10, 11:15 UTCUsers don't reinstall programs everyday, such a feature may be useful only for beta tests. Even in that case you don't need to install a new version immediately, I think.

Even if a user wants to install a new beta version immediately, there are several ways to do that without having to overwrite files in use:

• install to a new directory
• just extract the new files and renaming them in the process
• using a VM or sandbox
• and probably other ways

When testing beta versions there are probably not many TC instances running that can't be closed yet because they contain data needed for work anyway. So I agree that it's not really worth the effort.

Regards
Dalai

I have already made a suggestion which can be useful for such cases:
Add TC instance number to titles for separate (non-modal) windows

Dalai,

Isn't this the way it is now?

That was more of like a suggestion to the user.

Roman