When updating a backup of the file is created in case the update fails and we have to rollback the update. When an update is staged a copy of the install directory is used and if the update fails the copy is thrown away so backing up the files is not necessary. By not backing up the files when staging an update the process should be significantly faster.
For a add file, don't backup the file, delete the destination file if it exists, and extract the file. For a patch file, don't backup the file and just apply the patch. During cleanup, don't check for backup files. Though it is technically possible, none of these files should be in use and anything that causes these files to be in use would likely cause the copy to be in use as well.
Created attachment 8786939 [details] [diff] [review] patch rev1 Pushed to try https://treeherder.mozilla.org/#/jobs?repo=try&revision=bd8eda22f662
Assignee: nobody → robert.strong.bugs
Status: NEW → ASSIGNED
Comment on attachment 8786939 [details] [diff] [review] patch rev1 Try is looking good.
Attachment #8786939 - Flags: review?(mhowell)
Also pushed to oak so I can verify with a nightly build https://hg.mozilla.org/projects/oak/rev/8c2ab2591d71
Attachment #8786939 - Flags: review?(mhowell) → review+
So far the replace requests are failing with my manual testing but I don't know why yet. :(
The file "C:\Program Files (x86)\Nightly-oak\updater.exe" is signed and the signature was verified. Passed in path: 'C:\Program Files (x86)\Nightly-oak\updater.exe'; Using this path for updating: 'C:\Program Files (x86)\Mozilla Maintenance Service\update\updater.exe'. updater.exe was compared successfully to the installation directory updater.exe. The updater.exe application contains the Mozilla updater identity. The file "C:\Program Files (x86)\Mozilla Maintenance Service\update\updater.exe" is signed and the signature was verified. Starting update process as the service in session 0. Starting service with cmdline: "C:\Program Files (x86)\Mozilla Maintenance Service\update\updater.exe" C:\Users\rstrong\AppData\Local\Mozilla\updates\29ED94CD9B916133\updates\0 "C:\Program Files (x86)\Nightly-oak" "C:\Program Files (x86)\Nightly-oak\updated" 14200/replace "C:\Program Files (x86)\Nightly-oak" "C:\Program Files (x86)\Nightly-oak\firefox.exe" Process was started... waiting on result. Process finished with return code 1. updater.exe returned status: pending-service *** Warning: Error running update process. Updating update.status (0)*** Service command software-update complete. service command MozillaMaintenance complete with result: Failure. and then it falls back to applying the update directly to the install directory and that succeeds.
I ran numerous manual tests and haven't been able to reproduce the failure mentioned in comment #5 and comment #6... still looking.
So far complete updates are working correctly. I'll check partial updates tomorrow since there isn't a partial available at this time.
It turns out that partial mar generation has changed and is now controlled by https://github.com/mozilla-releng/funsize/blob/master/funsize/worker.py#L23 So, partials aren't generated on oak at this time. An email request has been sent to add oak to partial mar generation.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/acb9b2a2bc96 Don't create backup of files when staging an update. r=mhowell
Not going to wait on getting the partial mar generation since the tests passing give a high level of confidence.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox51: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
I manually verified that a partial update succeeds using Nightly so this looks good to me.
You need to log in before you can comment on or make changes to this bug.