310715 - Software update fails going from 2005093006 to 2005100107 nightly build

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[IU]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051001 Firefox/1.4.1

There is a bug is Software Update that make it fail when attempting to update
from the 2005093006 to 2005100107 nightly build


Reproducible: Always

Steps to Reproduce:
1. If you currently have Firefox installed, uninstall it and install the
2005093006 nightly build
2. Launch Firefox and install Nightly Tester Tools:
http://users.blueprintit.co.uk/~dave/web/firefox/buildid/nightly.html
3. Restart Firefox then click Help --> Check for Updates... . You will get "A
new version of Firefox is available:  Firefox 1.4 ..."
4. Click "Download and Install Now".  A 509 KB file will be downloaded and you
will receive the message, "The update was successfully downloaded and verified.
 you must restart Firefox so that the update can be installed."  Your current
build number should be indicated as Build 2005093006, in the Firefox title bar
5. Click "Restart Firefox Now"
6. After Firefox loads, you should notice that the build number is still
20053006, and you now have a Softare Update "Update Failed" dialog with the
message "The partial Update could not be applied.  Firefox will try again by
downloading the complete Update."
7. Click "Next" for the complete update.
8. Click "Restart Firefox Now," once the complete update has been downloaded
9. Once Firefox is up and running again, you will notice that your build number
is still 2005093006
10. Click Help --> Check for Updates... . You will once again get "A new version
of Firefox is available:  Firefox 1.4"  This is the exact same build as before.
11. If you continue with the update process, you can pretty much repeat steps 3
to 9 over and over. or...
12. Manually download and install the 2005100107 nightly build.
13. Only now should you notice that the build number has changed to 2005100107.

Actual Results:  
Software update fails to successfully perform either a partial update or
complete install.


Expected Results:  
Software update should have been able to successfully perform either a partial
update or complete install.

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051001
Firefox/1.4.1 ID:2005100105

WFM. The very first (partial) update changed the build to 1.8b5_2005100107.

Comment 2

[IU]

Strange.  Still reproducible here.  If you had to uninstall your previous
Firefox installation to test this, did you make sure to delete everything in the
old installation directory - with the exception of your plugins folder?

Comment 3

[IU]

Just saw this post by Peter(6) on Mozillazine (about a server distributing
corrupted builds): http://forums.mozillazine.org/viewtopic.php?p=1780574#1780574

Maybe this is why some people are getting successful updates and other, like
myself, are having problem?

Comment 4

[Jesse Ruderman]

I saw the same thing happen a few days ago.

Comment 5

[Jesse Ruderman]

I might still have the build that won't update, in case that helps.

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #2)
> Strange.  Still reproducible here.  If you had to uninstall your previous
> Firefox installation to test this, did you make sure to delete everything in the
> old installation directory - with the exception of your plugins folder?
>
Used a test profile, not my daily browser.
Ran a 30 september build and updated it, using the Help > Check for Updates
function.
Maybe your browser it is corrupted by previous installations?

Comment 7

[Ria Klaassen (not reading all bugmail)]

I used this (zip)build:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-09-30-06-mozilla1.8/
and of course I did not unzip it in a used directory.

Comment 8

[IU]

> Maybe your browser it is corrupted by previous installations?

Impossible, unless Firefox is leaving corrupt entries in the registry, as I have
both completely uninstalled and reinstalled Firefox, and used a default profile
to test this.

> I used this (zip)build:

That's why you could not reproduce the bug.

Interesting.  The problem is with the .exe builds.  I just tried that .zip build
and it works - Note: (as usual) I uninstalled, deleted everything but my plugins
directory, and unziped into the same folder.  Try the .exe build in the same FTP
directory and it fails!  I don't get why Mozilla doesn't package the same files
into the .exe builds as it does the .zip builds.  Obviously, next time I report
a bug, I will have to explicitly mention that it is to be verified with the .exe
build.

Comment 9

[IU]

There's definitely a bug with Software Update - that causes it to fail with
certain builds, when the browser is installed via the installer.  I just ran a
diff comparison between the .exe and .zip builds and these are the only differences:

.exe build (installed) has:
1. unistall directory
a) install_status.log
b) install_wizard.long

.zip build (unzipped) has:
1. removed-files

I see no reason why the above differences should have caused a failure. 
Therefore, I am assuming Firefox is being confused by its own registry entries.

Comment 10

[IU]

Typo in previous post.  That should have read:

b) install_wizard.log

Comment 11

[Benjamin Smedberg]

removed-files is probably causing this.

Comment 12

[IU]

> removed-files is probably causing this.

But removed-files is in the .zip build, which works, not in the .exe builds,
which fail.

Comment 13

[Benjamin Smedberg]

Attachment: Always ship the full removed-files

Comment 14

[Jay Patel [:jay]]

I have never used zipped builds, and I have seen this problem too trying to
update from 20050930 builds...on both the trunk and 1.5 branch.  

If this is something that will bite existing Beta 1 users, we might need to
consider taking it for Beta 2.  Not sure, so nominating.

Comment 15

[Darin Fisher]

Comment on attachment 198328 [details] [diff] [review]
Always ship the full removed-files

>Index: tools/update-packaging/make_incremental_update.sh

>+      if [ $patchsize -lt $fullsize -a "$f" != "removed-files"]; then

In some versions of bash, you need to insert a space before the
closing "]", so that line should be:

>+      if [ $patchsize -lt $fullsize -a "$f" != "removed-files" ]; then


r=darin (thanks for the patch)

Comment 16

[Benjamin Smedberg]

fixed on trunk

Comment 17

[Benjamin Smedberg]

Fixed 1.8

Comment 18

[Benjamin Smedberg]

<Chase> one system is responsible for making the partial patches
<Chase> it needs to be updated by hand

Comment 19

[Chase Phillips]

(In reply to comment #18)
> <Chase> one system is responsible for making the partial patches
> <Chase> it needs to be updated by hand

My words have been used against me! :-x

I'll update the tools/update-packaging/ directory on the partial patch packaging
system to nab this fix.

Comment 20

[Chase Phillips]

(In reply to comment #19)
> I'll update the tools/update-packaging/ directory on the partial patch packaging
> system to nab this fix.

Done.

Comment 21

[IU]

I've just run into this bug with the 20051003 build of Deer Park Trunk (failing
to successfully partial update to 20051004 then wanting to download the complete
install.  I disallowed this, because there is a bug with Software Update
applying a complete update and clobbering the uninstall log: Bug 310873).

Could someone please look into this?  Should I reopen this bug or should I file
a new one specifically for the Trunk builds?

Comment 22

[IU]

This is not fixed.  I just experienced this bug again (just now), as Firefox
(having sucessfully manually updated yesterday) has failed when auto update
kicked in and attempted, but failed to successfully apply the update for
2005100307 to 20051004XX after a restart.  This bug is also present on the
Trunks ( see my Comment #21 ).  Tempted to reopen, but I'll wait.