[DUG] How to replace a file currently in use (Windows)

[Kyley Harris]

Those are good points..

I should have been more clear in that I download the entire exe into memory
first (because its only 3mb compressed exe) and then after a full and
successful download I do the renaming etc etc :) and then save the file to
disk.

Otherwise you are completely right that having a half done exe would be a
bad thing :D

On Wed, Jan 19, 2011 at 12:23 PM, Paul Heinz <paul at accredo.co.nz> wrote:

> Kyley wrote:
>
> > I do it almost the same way..
> >
> > App.exe renames itself to App_old.exe while its running. then
> > it downloads app.exe each time app.exe starts it deletes any
> > app_old.exe that exist.  This way you never need to run a
> > different file.. effectively its the same thing.
> >
> > by doing it this way users on a network share always get the
> > latest copy, even if people are still running in memory the
> > old copy. The Old copy will be deleted as soon as all running
> > instances are stopped and someone runs the new version.
>
> Yes, it's a neat trick. Not many people seem to know that unlike Unix,
> whilst you can't delete an open file in Windows (including .exe and
> .dll), you can _rename_ them.
>
> To do the self-update trick, I have seen developers still using .bat (or
> .cmd) files to launch their app since you can delete the running
> .bat/.cmd file since the command interpreter loads the whole file into
> memory and then closes it before execution begins by design. This
> behaviour dates to the era of .bat files on floppies which got removed
> from the drive.
>
> I can suggest a few nuances for robustness. We check the timestamp on
> startup and download the updated copy to a .new file before doing the
> rename process.
>
> If the download attempt fails, we just skip the update attempt (for now)
> and proceed as normal. The update code needs to trap all exceptions
> otherwise a bad update can prevent use of the application. Not good.
>
> If you don't take this precauation, an interrupted download attempt by
> one client leaves an unrunnable partial .exe for everyone else and a
> spate of support calls. Also not good :-)
>
> We then delete .old and then rename the running .exe to .old before
> renaming .new to .exe. You can use numbered extensions for .old to deal
> with the fact that you can't delete the current one since someone is
> still running it. This is quite common on TS servers which support lots
> of clients.
>
> I then execute the newly downloaded and renamed .exe which has code to
> silently attempt to delete .old files on startup. I also pass a command
> line switch to indicate that this is a downloaded respawn.
>
> I do this to handle the case where for some reason, the timestamps are
> misbehaving such that there always seems to be an update available.
> Windows networking combined with Samba versions and phase of the moon.
> You don't want to livelock downloading and restarting endlessly. Also
> not good.
>
> Finally, often, the .old file(s) are not deletable on the first run
> since the new process commonly starts executing and hit the delete
> attempt before the old process has shutdown. They're essentially racing
> with each other and on dual core machines, the .new process starts
> immediately. But there is no harm in attempting to delete the .old
> file(s) everytime.
>
> This is probably more detail on self-updating than anyone wanted to
> know, but there you go :-)
>
> Any logical holes that people can spot in the above approach I'd be very
> glad to hear about. Many smart eyeballs makes even nasty bugs shallow!
>
> Cheers,
>   Paul.
>
> _______________________________________________
> NZ Borland Developers Group - Delphi mailing list
> Post: delphi at delphi.org.nz
> Admin: http://delphi.org.nz/mailman/listinfo/delphi
> Unsubscribe: send an email to delphi-request at delphi.org.nz with Subject:
> unsubscribe
>



-- 
Kyley Harris
Harris Software
+64-21-671-821
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20110119/6c392ad0/attachment.html