Elvas Tower: Updater Aborts - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Updater Aborts Rate Topic: -----

#1 User is offline   Genma Saotome 

  • Owner Emeritus and Admin
  • PipPipPipPipPipPipPipPipPipPipPipPipPip
  • Group: ET Admin
  • Posts: 15,337
  • Joined: 11-January 04
  • Gender:Male
  • Location:United States
  • Simulator:Open Rails
  • Country:

Posted 25 May 2017 - 05:11 PM

On occasion the updater aborts -- your problem, my problem, who knows whose problem, doesn't really matter. What does mater is the previous (working) version of the OR software can be removed before the abort, leaving the installation inoperable.

Please consider moving the to-be-replaced version into a "\old version_nnnn" directory so if something goes wrong it's easy to put things right (and if this is already being done, where did you hide it?).

Whether the "\old version_nnnn" directory is deleted at the very end of the install process or left as-is (to be emptied before filling it up again next time) is your call, I'm ok either way.

#2 User is offline   James Ross 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 5,490
  • Joined: 30-June 10
  • Gender:Not Telling
  • Simulator:Open Rails
  • Country:

Posted 26 May 2017 - 02:16 PM

View PostGenma Saotome, on 25 May 2017 - 05:11 PM, said:

On occasion the updater aborts -- your problem, my problem, who knows whose problem, doesn't really matter. What does mater is the previous (working) version of the OR software can be removed before the abort, leaving the installation inoperable.

Please consider moving the to-be-replaced version into a "\old version_nnnn" directory so if something goes wrong it's easy to put things right (and if this is already being done, where did you hide it?).

Whether the "\old version_nnnn" directory is deleted at the very end of the install process or left as-is (to be emptied before filling it up again next time) is your call, I'm ok either way.

The updater performs these steps when applying an update (it does none of this when simply checking for updates):

  • Check that \UpdateTest directory can be created and deleted
  • Delete \UpdateStage and \UpdateDirty if they exist from any previous updates
  • Create \UpdateStage directory
  • Download update to \UpdateStage\Update.zip
  • Extract \UpdateStage\Update.zip into \UpdateStage
  • Delete \UpdateStage\Update.zip
  • Verify that the update in \UpdateStage is valid
  • Move all files from \ to \UpdateDirty
  • Move all files from \UpdateStage to \
  • Even if an error occurs earlier: Delete \UpdateStage and \UpdateDirty

So the issue is that, no matter what, it always tries to clean up at the end. This is easy enough to change, and honestly I am not really sure why it was written to do that, even though it was likely me that wrote that bit.

In X3862 I have made two changes:

  • The updater only deletes \UpdateStage and \UpdateDirty on a successful update
  • The copying of files from \ to \UpdateDirty and \UpdateStage to \ have been split into separate functions purely so errors/stack traces will indicate which copy operation failed


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users