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

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[(not reading, please use [e-mail] instead)]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: 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)

Comment 2

[(not reading, please use [e-mail] instead)]

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.

Comment 3

[(not reading, please use [e-mail] instead)]

Attachment: work in progress patch, still need to test on windows, mac, linux.

Comment 4

[(not reading, please use [e-mail] instead)]

Attachment: updated patch, add more logging (see bug #367677).

Comment 5

[(not reading, please use [e-mail] instead)]

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.

Comment 6

[(not reading, please use [e-mail] instead)]

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?

Comment 7

[juan becerra [:juanb]]

Confirmed. This is a problem in Windows only.

Comment 8

[Jay Patel [:jay]]

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.

Comment 9

[(not reading, please use [e-mail] instead)]

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.

Comment 10

[(not reading, please use [e-mail] instead)]

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

Comment 11

[Carsten Book [:Tomcat]]

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.