Rename a running executable (exe) file [duplicate]

Question

We are trying to push updates to multiple servers at once and my manager has found that it is possible to rename running .exe file. Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.

I guess I need to clarify, He doesn't expect the old copy to magically update, he just expects them to keep running the old copy until they open the exe again, in which case it will then open the new one that has the name of the old one.

It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed. On my machine I have yet to be able to get it to work even in a loop.

My first and main question is this: Is it ever acceptable to do this. Should renaming a running executable ever be a valid scenario?

Secondly, if it is a valid scenario then how could one reliably do this? Our current thoughts are try a bunch of times using File.Move (C#) to do a rename and if it doesn't work then write out to an error log so it can be handled manually.

Fredella

You managed to rename a mapped executable image? I didn't know that this is possible on Windows with typical file systems. Which version of windows did you use? And which filesystem? Or was the file system a remote filesystem? – Sapp

@CodeInChaos: You can rename files that are in use... Why would it be any different for a managed executable? – Pean

In response to your update, that's still broken. Just do what everyone else does and restart the app when you need to update. As I mentioned below, any time you have to try something a bunch of times in order for it to eventually work, you should immediately step back and wonder why in the world that's happening. Where is the OS going to get the old copy of the executable, the one that it's currently running, from if the entire thing is not already loaded in memory? – Pean

@Cody Seems to be me misremembering stuff. I thought it doesn't work with native executables either. Did that change in some version of windows, or did I mix that up with other operations such as modifications not being possible once an image has been mapped? – Sapp

@CodeInChaos: Hmm, as far as I know it's always been possible on Windows NT. Maybe not the case on the 9x platforms, but I've never actually run one of those for longer than a few hours. This question seems to back up my memory. – Pean

I don't have previous experience with that, but I think it would be easier if you run the exe in the temp folder on the client computer. You can make an launcher.exe and myapp.exe the client execute launcher.exe and it download myapp.exe to the client temp folder and then execute it. So the myapp.exe is running locally on all computers, so you can replace the myapp.exe. they will get the update on the next launch. – Crim

Moving/renaming a running program or .dll has always worked for me as long as the target destication was on the same volume. It has never failed with an exception. I have a SafeDelete() function that generates a unique name with a .delme extension and renames the file to that, and a SafeCleanup() funcion that tries to detete all the .delme files in a directory. I wonder if it work on Linux... – Roye

Answer 1

An airplane mechanic and a surgeon meet in a bar. The mechanic says "you know, we have basically the same job. We take broken stuff out and put new, better parts in." The surgeon says "yeah, but you don't have to keep the plane flying as you're making the repairs!"

Trying to update an application by moving files while the application is running seems about as dangerous as trying to fix an airplane in flight. Possible? Sure. Greatly increased risk of catestrophic crash? Yep.

If the application you are updating is a managed application, consider using ClickOnce Deployment. That way, the next time someone runs the application, if there is a new version available it will be copied down and installed automatically. That's much more safe and pleasant than trying to mess with an application while its still running.

Fair

Just in case you were wondering if it's been done before: a CH-53 helicopter in Israel once had a serious malfunction in its landing gear which meant it couldn't land without causing serious amounts of damage and potential casualties (at least the pilots were in danger). The geniuses working for the air force designed and manufactured temporary parts on the helicopter while it was in the air, then replaced them while the helicopter was hovering very low above the ground. After about 20 hours in the air, including aireal refueling, it finally landed safely. – Older

Yet in Linux this is no big deal. – Keitt

Answer 2

1. No, this is not acceptable. Do not do this. This is not a valid deployment mechanism. This should have been yours or his first clue:

   It sometimes throws an exception that the file is in use on his program but if he tries renaming it in a loop it will eventually succeed.

   And it won't work, anyway. His theory is quite wrong:

   Using that knowledge he wants to rename a running exe and copy over a new version of said exe such that anyone running their in memory copy of foo.exe are fine and anybody who opens a shortcut pointing to foo.exe will get a new copy with updates applied.

   Specifically, the copy in memory will not be automatically replaced with the new executable just because it has the same name. The reason that you're allowed to rename the executable in the first place is because the operating system is not using the file name to find the application. The original executable will still be loaded, and it will remain loaded until you explicitly unload it and load the new, modified executable.

   Notice how even modern web browsers like Chrome and Firefox with their super fancy automatic, in the background, no one ever notices that they exist, updaters still have to close and relaunch the application in order to apply the updates.

   Don't worry about shooting the messenger here. It's more likely that your customers and your tech support department will shoot you first.

2. See number 1.

Pean

AFAIK on unixoid systems this is considered a valid way of updating. – Sapp

Windows is probably different from UNIX more places than it is the same. You need to adapt your methodology to the platform, rather than expecting the platform to conform to your methodology. I know nothing about UNIX, so I can't possibly confirm or deny that statement. But it's definitely not the idiomatic way of updating apps in Windows, and I very much caution against it for technical and maintainability reasons. – Pean

Just FYI, this is 100% standard on GNU/Linux systems; for example upgrading Debian / Ubuntu packages with apt-get update will unlink (delete) the old file and write a new one of the same name. (Or extract and rename). A still-running process will be like another reference to the file, so the FS doesn't free its space until the last name and the last open usage are gone. ls -l /proc/<PID>/exe will show something like /usr/bin/chromium (deleted) until you restart your web browser. Things only get wonky when an old process tries to open by name files with contents it didn't expect. – Barometry

I had no experience whatsoever with development on GNU/Linux systems when this answer was posted. It was true then for Windows, and remains true for Windows now. – Pean

Answer 3

In our organization, we solved the problem of Updates by having two release folders say EXE_A and EXE_B. We also have a release folder called EXE which only has links ALL of which points to either to EXE_A or EXE_B from which the user runs the applications.

When we publish a new version of the program, we publish it to the folder that is not referenced in the links and then update the links (EXE). In this way, you do not get into exceptions that users are holding the application / assemblies. Also if a user wants to run the updated version, all he need to do is close / re-execute the link in EXE folder.

Volny

This is about the worst, most error-prone deployment mechanism I can imagine. Follow this advice at your own peril... – Pean

Why do you say that? We use a similar strategy and it works fine. – Week

Answer 4

If you use Windows Vista/Server2k8 or newer you could use mklink to create a symbolic link to the folder containing your application and start the application out of the "symblic linked folder" and then at the update create a new folder, e.g. "AppV2" and change the SymLink to that folder, so the next time the user restarts the application he starts it out of the new folder without noticing.

Renaming open files is ALWAYS a bad choice!

But in general I would think of a better deployment strategy anyway, because if you need to use such "hacks" it is always a messy situation. I don't know your application, but maybee ClickOnce would be a point to start, because you can configure it to check for updates on every start...

Shalloon