453693 - updater.exe sometimes creates the lock file in the wrong directory

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Robert Strong (they/them - no direct email)]

This is due to the working dir not always being set to the directory where the binary lives.

Comment 1

[Robert Strong (they/them - no direct email)]

Attachment: patch rev1 - use argv[4] which is the callback binary and append .update_in_progress.lock to the file name

Comment 2

[Robert Strong (they/them - no direct email)]

Comment on attachment 336901 [details] [diff] [review]
patch rev1 - use argv[4] which is the callback binary and append .update_in_progress.lock to the file name

Drivers, I'd like to get this simple fix for 1.9.0.3. There are some cases where the working dir is not the same as the app dir.

Comment 3

[Robert Strong (they/them - no direct email)]

Checked in to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/e17fa56c1f5b68b8dd552c4b4a7ecd0c956d35e1

Comment 4

[Samuel Sidler (old account; do not CC)]

Doesn't really meet the "wanted" criteria (security, stability, regression from maintenance release) for 1.9.0.x. However, we'll look at the patch later.

Comment 6

[Robert Strong (they/them - no direct email)]

Comment on attachment 336901 [details] [diff] [review]
patch rev1 - use argv[4] which is the callback binary and append .update_in_progress.lock to the file name

Drivers, it appears there are some edgecases where this is causing problems with Firefox 3.0.x such as bug 458884.

Comment 7

[Daniel Veditz [:dveditz]]

Comment on attachment 336901 [details] [diff] [review]
patch rev1 - use argv[4] which is the callback binary and append .update_in_progress.lock to the file name

Approved for 1.9.0.4, a=dveditz for release-drivers.

What is the test scenario for QA to make this "sometimes" into an "always" so it can be verified?

Comment 8

[Robert Strong (they/them - no direct email)]

This has worked for me previously and should be enough.

Create a shortcut to firefox.exe and set the working directory to a directory that the user doesn't have permissions to. Run Firefox twice and perform the software update on the second run.

Comment 9

[Robert Strong (they/them - no direct email)]

Checked in for 1.9.0.4 / Firefox 3.0.4

Checking in mozilla/toolkit/mozapps/update/src/updater/updater.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/updater.cpp,v  <--  updater.
cpp
new revision: 1.39; previous revision: 1.38
done

Comment 10

[Robert Strong (they/them - no direct email)]

Due to this bringing up the UAC dialog there is no way to create a unit test.

Comment 11

[Robert Strong (they/them - no direct email)]

(In reply to comment #8)
> This has worked for me previously and should be enough.
> 
> Create a shortcut to firefox.exe and set the working directory to a directory
> that the user doesn't have permissions to. Run Firefox twice and perform the
> software update on the second run.
Also, this test should be done on Windows XP.

Comment 12

[Aakash Desai [:aakashd]]

Are there an easier steps to reproduce for this bug other than the one mentioned in comment #8 , Robert? It's going to be difficult to make this into a Full Functional Test otherwise.

Comment 13

[Robert Strong (they/them - no direct email)]

Regretfully there isn't.