1925144 - [meta] Exclude duplicate instances of updater.exe from updating at the same time

Status: NEW

(Toolkit :: Application Update, defect)

Description

[Chris DuPuis]

One class of issue that is sometimes seen in the updater is where one instance of updater.exe is apparently running at the same time as another instance from the same installation, resulting in errors in applying the updates to the filesystem.

This bug tracks work to ensure that an installation of Firefox has no more than one updater.exe process updating files at a time.

It is possible that this kind of exclusive access will be unnecessary once versioned install directories (https://bugzilla.mozilla.org/show_bug.cgi?id=1891600) are delivered, but it is also possible that locking in this executable will still have value.

Comment 1

[Chris DuPuis]

Planned work for this meta bug:

• Develop locking and signaling approach for updater.exe. Required pieces:

  • Locking must be implemented in updater.exe, to avoid edge cases that occur in current model where firefox process handles lock.
  • Only one process may hold the lock, and the lock must be held before starting to modify installation
  • Lock must cover any usage of updater.exe, regardless of what profile is involved
  • Locking status should be observable without acquiring a lock. This is needed for UI integration, where knowing that an update is already in flight can allow us to communicate that status to the user. firefox.exe is an observer of the lock, but not a holder of the lock.

• Add UI treatment showing when an update is already in flight.

  • Must support cases where a different profile/user is updating the installation
  • Disable UI controls for launching update when an update is in flight
  • Possibly provide additional information about in-flight update: when update started, guesstimated completion percentage, who is updating, etc.