Steps to reproduce: 1. Use NSMacInstaller to download and install a build (ie 1999121308) 2. Test etc 3. Clean system (delete mozregistry.dat/Documents or profile folder) and prepare for new tests on 1999121408 build 4. Use NSMacInstaller to download and install build 1999121408 Actual results: Some files have 1213 dates (see also bug 21182), seamonkey shows build date of 1999121308 Expected results: All files would have current 12/14 date and build date would be 1999121408 Workaround: Restart system, browser.xpi file is still residing in Temp folder and part of reboot is to clean that directory. If installer sees any .xpi file, it will not download a new one - see bug 15695
Raising the severity to critial and nominating for dogfood, because - the mac temp file is invisible so you won't see it unless you go look at it - users don't always reboot their Mac. (I reboot my Mac everyday...of course I crash everyday too :-)) - this is really confusing and may cause additional bugs being logged that have been already been fixed my 2 cents /Peter
changing assigned to Samir
Samir, I thought that the .xpi files get cleaned up after the install is done?
The extracted core files get cleaned up, not the .xpis cause at the shutdown stage we don't have any notion of whether they were already there or not (that's still an open area until we implement MD5 checksums in the config.ini). At any rate, we explicitly ask SmartDownload to download the .xpis. Need to investigate whether SmartDownload is making the decision not to download if they already exist, or we are.
Putting on PDT+ radar.
Fix checked in.