for 184.108.40.206 -> 220.127.116.11 de updates, only offer the partial this depends on bug #367084, which will be a fix to updater.exe that will fix the users default files (and remove the read only attribute) so that a future, complete upgrade (or a future, partial upgrade to those default files) will succeed. we can't offer them a complete update, as that will fail and leave them in a state where they can never (automatically) update again.
linux 18.104.22.168 de had this bug, so we might want to do the same thing there, too. the 22.214.171.124 app.update.url format doesn't have the OS_VERSION, but it does have the build target (%BUILD_TARGET%), so we should be able to tell linux from mac and windows.
Summary: for 126.96.36.199 -> 188.8.131.52 de updates, only offer the partial → for 184.108.40.206 -> 220.127.116.11 de [all] and 18.104.22.168 -> 22.214.171.124 [linux] updates, only offer the partial
from bug #367084, this doesn't appear to be a problem for 126.96.36.199 linux, or 188.8.131.52 linux/mac, only 184.108.40.206 windows. from my tests, only windows will fail on a complete software update if, for example, bookmarks.html is "read only". (For the other platforms, remove() of a file with perms of 0400 will succeed.) juan, can you confirm? If I'm right, and not seeing things, then for this bug all we'll need to work about is windows, 2001, de, and for them, only serve the partial update with the fix for bug #367084.
at todays meeting, preed emphasized that we can serve partials to broken 220.127.116.11 de windows users, as long as nothing has changed since 18.104.22.168 rob helmer and I just double checked that in the l10n/de/browser/profile on the MOZILLA_1_8_BRANCH directory, no changes have been made since 22.214.171.124 (we did a cvs diff -r FIREFOX_2_0_0_1_RELEASE) So, as long as no one changes those files before 126.96.36.199, we should be ok. c'ing axel, so that he can prevent changes to l10n/de/browser/profile on the MOZILLA_1_8_BRANCH.
juan confirms this is windows only. see bug #367084 comment #7. updating summary.
Summary: for 188.8.131.52 -> 184.108.40.206 de [all] and 220.127.116.11 -> 18.104.22.168 [linux] updates, only offer the partial → for 22.214.171.124 -> 126.96.36.199 de [windows only] updates, only offer the partial
Assuming for a minute that the partial update fails for a user, what happens? Do we have any numbers of the downloads of the full updates to get an idea how often that happens? And are all those working on admin-installed firefoxes with user accounts? Just wondering.
In the future, when we release 188.8.131.52, we need to keep 184.108.40.206 de windows to be a partial update to 220.127.116.11, as a complete from 18.104.22.168 -> 22.214.171.124 will fail (for the same reason that 126.96.36.199 -> 188.8.131.52 complete will fail.). These users will be forced to go from 184.108.40.206 -> 220.127.116.11 (by partial), and from there, go to 18.104.22.168 (and beyond.)
Summary: for 22.214.171.124 -> 126.96.36.199 de [windows only] updates, only offer the partial → for 188.8.131.52 -> 2.0.0.x de [windows only] updates, only offer the partial
this AUS / patcher tweak for windows should block 184.108.40.206-de
Preed: Is this simply a change to the snippet to serve partial patch for both the partial and complete update paths? If so, you should be the owner.
Flags: blocking220.127.116.11? → blocking18.104.22.168+
Whiteboard: [software update config]
Reassigning to Preed after discussing this with him. We are not going to be making any AUS server side changes, so we need to make sure we create snippets that only serve partial patches.
Assignee: morgamic → preed
for the partial that we offer to 22.214.171.124, we can't include changes to these files: ./defaults/profile/bookmarks.html ./defaults/profile/chrome/userChrome-example.css ./defaults/profile/chrome/userContent-example.css ./defaults/profile/localstore.rdf ./defaults/profile/mimeTypes.rdf ./defaults/profile/search.rdf ./README.txt ./searchplugins/amazondotcom-de.xml ./searchplugins/eBay-de.xml ./searchplugins/wikipedia-de.xml ./searchplugins/yahoo-de.xml (determined using a bad 126.96.36.199 de build, and "find ./ -not -perm -u=w" (thanks rhelmer!)
Can we do this one more time for all builds? I did see watches in particular on search plugins (may have been old sherlock ones, though), so I'm not that sure. In addition, is this still windows only? I saw another bug comment talking about the linux build, too.
> Can we do this one more time for all builds? axel, rhelmer did it last night and I he found and removed all the watches under l10n/de. > In addition, is this still windows only? yes, we only need to provide the partial updates to windows, as the updater on mac and linux are able to remove files with read only permissions.
note, jay and I just met and triple checked and confirmed that yes, we really do need to do this. otherwise, here is what could happen to 188.8.131.52 de users if we serve the a complete update. they will first get a prompt: "one or more files could not be update. please make sure all other appications are closed and that you have permission to modify files, and then restart" on restart, under the help menu, they will have "apply downloaded update now..." since the update.mar on disk is ok, and the status is pending. they are now stuck in this loop and will get the prompt again. I believe the plan is to offer a true partial and a complete, which is really the partial. if a user fails both partials, they might be hitting the dreaded update.status == null problem that leaves the user stuck. jay and I were able to reproduce this (by failing both partials by setting update.status == failed). i believe there is a bug on the update.status == null issue, I'll go find it.
> i believe there is a bug on the update.status == null issue, I'll go find it. see bug #333908
We ended up releasing the partial because it was causing problems for .de users in the normal state... as I remember. But 184.108.40.206 has shipped, so...
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.