Closed Bug 453693 Opened 16 years ago Closed 16 years ago

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

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
1.9.0 Branch
Platform:
x86
Windows Vista
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1b1

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

References

Details

(Keywords: fixed1.9.0.4)

Attachments

(1 file)

patch rev1 - use argv[4] which is the callback binary and append .update_in_progress.lock to the file name
(deleted), patch
ted
: review+
dveditz
: approval1.9.0.4+
Details | Diff | Splinter Review
This is due to the working dir not always being set to the directory where the binary lives.
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
Closed: 16 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-
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.

Attachment

General

Creator:
Created:
Updated:
Size: