If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Don't create backup of files when staging an update

RESOLVED FIXED in Firefox 51

Status

()

Toolkit
Application Update
P3
normal
RESOLVED FIXED
a year ago
a year ago

People

(Reporter: rstrong, Assigned: rstrong)

Tracking

unspecified
mozilla51
Points:
---

Firefox Tracking Flags

(firefox51 fixed)

Details

Attachments

(1 attachment)

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.

Comment 10

a year ago
Pushed by rstrong@mozilla.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.

Comment 12

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/acb9b2a2bc96
Status: ASSIGNED → RESOLVED
Last Resolved: a year 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.