[wpkg-users] WPKG client upgrade

[Rainer Meier]

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