staged updates fail on Windows
On Windows, staged updates currently fail (I am not sure if they ever worked correctly, but I think they have not been working at least since MAR signing was introduced). The good news is that typically users do not notice the failure because the updater silently falls back to doing an in-place update. The failure occurs after the user restarts their browser to apply the update: switching to the staged copy that is under Browser/updated fails because files are in use under the Browser directory, and Windows does not allow a directory to be renamed if any open handles point to files within the directory or if any DLLs located in the directory are in use (at least that is my understanding based on my limited knowledge of system behavior on Windows).
To fix this we will need to do two things:
- Copy updater.exe and the DLLs it uses into a temporary directory and run it from there.
- Modify the updater.exe code to not open and hold onto a handle for a log file that is located under Browser/TorBrowser.
Because these changes will not be trivial to implement and test, I propose that for the stable branch of Tor Browser (5.5) we disable staged updates on Windows. That is a safe thing to do and it will speed up updates since currently updates are applied twice (one time to stage the update, which then fails, and a second time to do an in-place update, which succeeds). Of course we should fix this correctly for TB 6.0 and test it during one or more of our alpha cycles.
One challenge is knowing which of our bundled DLLs the updater depends on. The set of DLLs might change over time, and some components such as NSS load DLLs at runtime (so it is not just a matter of checking DLL dependencies by dumping linker info from updater.exe).
This ticket was split off from legacy/trac#18170 (moved).