While working on my software update test for Mozmill I have noticed that we don't trigger a fallback upgrade if the crash reporter is missing in the application folder. We are doing this on 1.9.1. That means if the application was somehow moved away (e.g. after it was infected by a virus) we never recreate it. The user has to download a full update so it will be restored again. This is only an issue on 1.9.0. Seen while upgrading from 3.0.12 => 3.0.13.

Looking at the partial updates for 3.0.11 -> 3.0.12, and 3.5.1 -> 3.5.2 (for mac en-US), this is a direct consequence of the crashreporter not changing between releases on 3.0, where it does for 3.5. Possibly something in the build system is different to ensure that. Note that binaries always change on windows (msvc), because they end up with some sort of magic number embedded in them, but that's not true on linux and mac (gcc). Why not pick something that is guaranteed to change, like Contents/MacOS/XUL or Contents/Info.plist ?

(In reply to comment #1) > Why not pick something that is guaranteed to change, like Contents/MacOS/XUL or > Contents/Info.plist ? I cannot remove/rename those files/folders because they are needed by Firefox. If they aren't present anymore I'm not able to download the full mar anymore afterward. A further discussion should be moved to bug 504653.

Doubt we'll try to do anything for this and I'm not sure how a contrived scenario that is used for testing software update and has not been reported by users would be considered major. We also don't try to recover from any other binaries being removed by virus software - not that we have had any issues with this happening in the real world - and if it did happen the solution would be to get the anti-virus vendor to fix their software.

Don't we have tests to identify open issues? For me it sounds like that they are not useful in this area. Given the fact that it hasn't been reported yet shouldn't stop us to think about this issue. As Nick said it will not happen on Windows and while looking at the very low virus infection rate on OS X and Linux systems gives me the impression that we will never run in this case. But if it will happen how big is the chance that a user can see this problem? Ideally no-one should be affected by a crash. Means no-one will recognize that the crash reporter is missing. Normal users even don't know about this feature. Further, we got it fixed on 1.9.1. That means something has been changed for Firefox 3.5. If it is not worth back-porting to 1.9.0 feel free to close this bug as wontfix. I just wanted to point to this malfunction for partial updates.

(In reply to comment #4) > Don't we have tests to identify open issues? For me it sounds like that they > are not useful in this area. Given the fact that it hasn't been reported yet > shouldn't stop us to think about this issue. Hence why I didn't close it... I am thinking about it and so far don't think it is worth fixing on 1.9.0. > As Nick said it will not happen on Windows and while looking at the very low > virus infection rate on OS X and Linux systems gives me the impression that we > will never run in this case. But if it will happen how big is the chance that a > user can see this problem? Ideally no-one should be affected by a crash. Means > no-one will recognize that the crash reporter is missing. Normal users even > don't know about this feature. Even with virus infection rates being higher on Windows the fact that we haven't had a bug report on this I highly suspect your rationale about the virus infection rate being low on Mac OS X and Linux also applies to the crashreporter and other critical Firefox files on Win. > Further, we got it fixed on 1.9.1. That means something has been changed for > Firefox 3.5. Nothing changed in app update that made this work on 1.9.1 and above... the way files are built is what changed. > If it is not worth back-porting to 1.9.0 feel free to close this bug as > wontfix. I just wanted to point to this malfunction for partial updates. What you call a malfunction is that app update doesn't try to update files it doesn't have an update for and this is the case for 1.9.1 and above. resolving -> wontfix