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

RESOLVED FIXED in mozilla1.9.1b1

Status

()

Toolkit
Application Update
RESOLVED FIXED
10 years ago
8 years ago

People

(Reporter: rstrong, Assigned: rstrong)

Tracking

({fixed1.9.0.4})

1.9.0 Branch
mozilla1.9.1b1
x86
Windows Vista
fixed1.9.0.4
Points:
---
Bug Flags:
wanted1.9.0.x -
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

This is due to the working dir not always being set to the directory where the binary lives.
Created 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
Attachment #336901 - Flags: review?(ted.mielczarek)
Attachment #336901 - Flags: review?(ted.mielczarek) → review+
Flags: wanted1.9.0.x?
Version: Trunk → 1.9.0 Branch
Attachment #336901 - Flags: approval1.9.0.3?
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.
Checked in to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/e17fa56c1f5b68b8dd552c4b4a7ecd0c956d35e1
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1b1
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.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
Duplicate of this bug: 458884
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 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?
Attachment #336901 - Flags: approval1.9.0.4? → approval1.9.0.4+
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.
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
Keywords: fixed1.9.0.4
Due to this bringing up the UAC dialog there is no way to create a unit test.
Flags: in-testsuite-
Flags: in-litmus?
(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.
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.
Regretfully there isn't.
Flags: in-litmus?
You need to log in before you can comment on or make changes to this bug.