Hi Marco Marco Gaiarin wrote: > A question (but i'm a unix guy): for me it is normal to upgrade binary > in execution, simply the newer version will be available next time we > reboot the machine. > > Asked in another way: why not rewrite the installer so it handle all > this stuff, upgrade the binary and then force a reboot? I am working on Unix systems as well. I agree that on Unix systems you can easily replace a file which is currently opened by another process. The file handle will just continue to exist as long as not closed by the application holding it. Unfortunately on Windows it is different. Files which are in use are locked and cannot be deleted/exchanged/upgraded/modified/whaterver, except read. As a result it is not possible to overwrite these binaries while they are running. However I thought to remember that installers can queue pending renames/replaces and the likely for the next reboot. So WPKG client can continue to run and on next reboot these files are replaced even before any other service is loaded. As far as I understood this operations are even executed before any other service is loaded. Unfortunately I don't know yet by heart how to do it but the installer framework should provide such functionality by configuration. I even don't know yet which installer we use for WPKG client. This is also one of the main reasons why some applications require a reboot - simply because the files are in use currently. There are also some installers requesting a reboot only if the application was currently running when doing an upgrade. If it was not running it is replacing the files immediately. I am quite sure Windows installer must support something like this as a built-in service. It's an ugly work-around trying to kill applications which are currently running just to unlock these files. Especially since you never know which other applications (indexing serivice, 3rd party tools...) open the same file. So replacing a file might fail at any time. I think that's exactly the reason why an installer can queue such changes in order to be executed at next reboot. If somebody knows more about it - feel free to support us. br, Rainer |