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 <p...@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@delphi.org.nz > Admin: http://delphi.org.nz/mailman/listinfo/delphi > Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: > unsubscribe > -- Kyley Harris Harris Software +64-21-671-821
_______________________________________________ NZ Borland Developers Group - Delphi mailing list Post: delphi@delphi.org.nz Admin: http://delphi.org.nz/mailman/listinfo/delphi Unsubscribe: send an email to delphi-requ...@delphi.org.nz with Subject: unsubscribe
