updater will fail to apply any complete updates if *any* files are "read only"

VERIFIED FIXED

Status

()

Toolkit
Application Update
VERIFIED FIXED
12 years ago
10 years ago

People

(Reporter: (not reading, please use seth@sspitzer.org instead), Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({verified1.8.1.2})

1.8 Branch
x86
Windows XP
verified1.8.1.2
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [landed on trunk and MOZILLA_1_8_BRANCH])

Attachments

(2 attachments, 1 obsolete attachment)

complete updates will fail if any files are "read only"

spun this off bug #364599

fx 2.0.0.1 de users will hit this with fx 2.0.0.2 (unless they get a partial update first that includes a fix and doesn't include any changes to those read only files.)

the error message the user will see is:

"The update could not be installed.  Please make sure there are no other copies of Firefox running on your computer, and then restart Firefox to try again."

I'll attach a screen shot.

On disk, the user will see files like defaults\profile\bookmarks.html.moz-backup.

these are created during the complete update, when we try to move aside bookmarks.html, and fail because it is read only.

note, once in this state, the user is stuck.  they will only see "Help | apply downloaded update now" in firefox, as there is an update downloaded, with status "install pending".

see bug #364599 comment #68 for more details.
Summary: complete updates will fail if any files are "read only" → updater will fail to apply any complete updates if *any* files are "read only"
Created attachment 251602 [details]
this is what fx 2.0.0.1 de users who hit bug #364599 will see on a complete update (except it will be in german, of course)
I think we should fix (what we can) for fx 2.0.0.2, and make updater.exe ignore the "read only" attribute / chmod the application owned files on update.
Assignee: nobody → sspitzer
Created attachment 252068 [details] [diff] [review]
work in progress patch, still need to test on windows, mac, linux.
Status: NEW → ASSIGNED
Flags: blocking1.8.1.2?
Flags: blocking1.8.0.10?
Whiteboard: wanted on MOZILLA_1_8_0, MOZILLA_1_8 and trunk
Version: Trunk → 1.5.0.x Branch
Flags: blocking1.8.1.2?
Flags: blocking1.8.1.2+
Flags: blocking1.8.0.10?
Flags: blocking1.8.0.10+
Created attachment 252261 [details] [diff] [review]
updated patch, add more logging (see bug #367677).
Attachment #252068 - Attachment is obsolete: true
on mac os x 10.4.8 and linux (ubuntu) a file of perms 0400 does not affect software update, as the remove() call will succeed.  

so, not changing the perms won't affect software update, but we should still add 0600 to files, as leaving the user with 0400 files can lead to problems, like bug #364599.  For #364599, I've added code to fix the perms of localstore.rdf, mimeTypes.rdf and bookmarks.html for user's per profile files, but having updater fix the perms of the "application" files seems like good prevention.

I'll attach a final patch for review.
to clarify, from my actual testing on mac (of an old bon echo to a new bon echo nightly, via a complete update) having a read only (0400) bookmarks.html does not impact update.

so this update problem is is a windows only issue.

juan or carsten: can you confirm?
Attachment #252261 - Attachment description: updated patch, add more logging (see bug #367677). tested on window, need to test on mac and linux. → updated patch, add more logging (see bug #367677).
Attachment #252261 - Flags: review?(benjamin)

Comment 7

12 years ago
Confirmed. This is a problem in Windows only.

Updated

12 years ago
Attachment #252261 - Flags: review?(benjamin) → review+

Comment 8

12 years ago
Comment on attachment 252261 [details] [diff] [review]
updated patch, add more logging (see bug #367677).

Approved for 1.8 branch only, a=jay for drivers.
Attachment #252261 - Flags: approval1.8.1.2+

Updated

12 years ago
Flags: blocking1.8.0.10+

Updated

12 years ago
Whiteboard: wanted on MOZILLA_1_8_0, MOZILLA_1_8 and trunk → wanted on MOZILLA_1_8 and trunk
this is not a problem on the MOZILLA_1_8_0 branch because only linux was affected there and is a windows only problem.

I'll go land on trunk and MOZILLA_1_8_BRANCH now.
Version: 1.5.0.x Branch → 2.0 Branch

Updated

12 years ago
Whiteboard: wanted on MOZILLA_1_8 and trunk → needs landing on Trunk and 1.8 branch
fix landed on trunk and MOZILLA_1_8_BRANCH.  as noted earlier, we're not going to land this on the MOZILLA_1_8_0_BRANCH.

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

Checking in updater.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/updater.cpp,v  <--  updater.
cpp
new revision: 1.11.4.11; previous revision: 1.11.4.10
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8.1.2
Resolution: --- → FIXED
Whiteboard: needs landing on Trunk and 1.8 branch → [landed on trunk and MOZILLA_1_8_BRANCH]
Verified fixed for 1.8.1.2 after updatetests on Windows XP x64. tests from Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070127 BonEcho/2.0.0.2pre -> Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070128 BonEcho/2.0.0.2pre and some read-only files.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.2 → verified1.8.1.2
Depends on: 381073
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.