User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: Mozilla/5.0 1.5 beta2 When updating from firefox 1.5 beta2 to 1.5 rc1 automatically if the free space of the hard drive is null the update process crashes. After that the executable file is unusable. As solution you can test the hard disc free space before starting to update. Reproducible: Didn't try Steps to Reproduce: 1.I supose that is necesarilly to have less than 20 MiB of free space when starting to update (automatically so it is imposible to say no or yes to the download) 2. 3. Actual Results: The executable file (firefox.exe) is unusable when the update process is broken. Expected Results: The software should test the free space after start the update process I think it's an important bug because is something that happens allways when a new release comes out (and this operation happens about 50 million times per new release) and usually people doesn´t have enough space to install the new release. Thank you.

The update process is supposed to handle low-diskspace conditions gracefully. It sounds like it does not :-(

too late for 1.5. It'd be nice to get this bulletproofed for 1.8.1

I just ran into this. While the error message I get mentions the possibility of permission problems and reminded me of closing all instances of firefox it did not mention that the diskspace could be low so it took me a moment to realize what was going on. Maybe the error could be changed like this as a workaround until this bug is fixed: "One or more files could not be updated. PLease make sure all other applications are closed, you have permission to modify files and that you have enough free disk space, and then restart Firefox to try again."

This issue has a major impact on Portable Firefox and Mozilla Firefox for U3 as USB thumbdrives and portable hard drives are FAR more likely to have low disk space than a standard hard drive. At the moment, they are set to auto-update for security purposes. But, I think I may simply have to turn that off due to this issue. It just nailed one of our developers this morning and he was left with a corrupt Firefox install.

Darin - any chance you'd have some time to look at this for FF2?

Darin, can you give us an estimate on the difficulty to fix this? Or a likely person who could help us fix it? (cc'ing mwu in case he wants to look at it, since I saw his fingerprints on another updater bug a while back ... :)

I've just retried this bug and it is still happening. I've tried it with just 24 free MB in my HDD. and without any other previous installation. The problem happens at the end of the installation process is like if everything would have been righ but when i clicked to finish the installation and to run Firefox nothing happens, finally searching in the instllation path there's no .exe file.

I can't get back to my home computers from OSCON, so this will have to wait until next week. I don't think it should block, because it's a fairly unusual situation. But I'll certainly look into it, and I expect that any potential fix would be low-risk and could be landed in a 2.0.0.1 and 1.5.0.6.

Based on Benjamin's comment, pushing to the nom list to consider pushing to 2.0.1

Moving out to 2.0.1

I just tried to reproduce this and couldn't: winxp on an USB stick... the process failed to update and reverted all changes correctly. Does anyone have more information that can help: 1) exact amount of free disk space after the MAR was downloaded and before it was applied 2) what OS and updates are being used 3) whether the update is a partial or complete MAR 4) anything else that might help me reproduce

(In reply to comment #11) fyi: MAR is Mozilla Archive, a non-standard format used to distribute updates to Mozilla products. More info at http://wiki.mozilla.org/Software_Update:MAR

Hi, I have exactly the same problem. Firefox completed update but when I wanted to run it, I got an error message about a bad exe file. I uninstalled it, downloaded the last version 1.5.0.7. I began to install the new version and at 1/3 of copying processus it stopped with an error message saying that there was not enough free space on my hard drive. That is the way i discovered why the update failed. Is that normal that the install process did not check free space before copying files ? I already had this bug with a precedent release OS: XP Firefox : 1.5.0.6

I have recently experienced this on a Windows 2000 machine with all of Micrsoft's last updates to that OS, running what I believe was a recent version of Firefox. I apologise, since it was not my computer, and I did not think to write down which version it was. I believe it was a 2.0.0.x release of Firefox and a 1.5.x release of Thunderbird. (Both had the same problem.) There was almost no space on the drive. About 700kB, if my memory serves correctly. That was on the primary system drive. A thought on recreating this issue: It may not be sufficient that just the Firefox program directory is on the drive with no space. Especially if the updater unpacks anything to %TEMP% or some other location. Before finding this bug, I made some general comments on thoughts about the software update process in bug 340535 comment 151.

No clear reproduction (see comment 11) and lack of massive dupes makes me think this isn't severe enough to block Firefox 3.

A former co-worker run into the same issue yesterday while upgrading Thunderbird to the new 2.0.0.12 version. His computer is a bit old and also has a small hard drive. That's why the upgrade process fails due to less disk space. There were only 20MB available. The result is that at least thunderbird.exe isn't fully patched and remains half-written on disk. That means only 3MB of 8MB are written. The result is that Thunderbird cannot be started anymore. No idea if the update process has crashed because he couldn't answer me that question. But anyway, there should be a check for free disk space before starting the upgrade. And if it still fails we should revert to the old version and show a warning to the user. The current behavior is less than ideal. The thing that there are less dupes of that issue is only that mostly all users have enough free disk space nowadays. But that shouldn't be a reason to stop working on that. It totally breaks the application and forces the user uninstall the broken version and to manually re-install the new version. I'll leave the Version field to 2.0 for now because I'm not able to test it with a current nightly build. But I think that I could run a test during the upcoming weekend under VMware.

Comment 18 exactly describes what happened to me. I can confirm this behavior. It seems that the exe was not fully written on disk but it was replaced tough. Consequence was that on the next start I got the message "no valid Windows application". However before the correct exe was replaced with the broken one, Firefox reported twice that the Update was not successfull, and on the 3rd start it tried again to Update and finally replaced the working exe with the broken one. Maybe I didn't have enough space for writing the EXE at all the first two times I started FF, and on the 3rd try had enough space so that FF could write a part of the exe on the HD?

I was able to make a test yesterday while upgrading Thunderbird 2.0.0.9 to the newest security release 2.0.0.12. Before the update process starts there were about 20MB free space on the hard drive. But that's not enough for the updater. After a while - the progress indicator doesn't show any update - the updater closes itself and Thunderbird 2.0.0.9 starts again. A warning box pops-up which told me that Thunderbird could not be updated. That's ok. But now I tried to find out what happens if you have a bit more space available as needed at minimum. I deleted some small files to have 25MB free space. I started the updater again. Now the progress indicator gets updated and means that the updater modified files on the hard disk. After some secs the updater was closed again. But this time starting Thunderbird failed with another problem as already stated in my comment 18. Now I get an empty gray window with a red arrow and nothing more. I checked the application directory and noticed that some files were already modified. These are: toolkit.jar, comm.jar, messenger.jar, AccessibleMarshall.dll, compreg.dat, and xpti.dat. All other files have the old access time. It looks like that there was an error with patching the next file in the list. I'll attach the last-update.log which will show this failure. I also made a backup of the broken application folder and the update files. If needed I can hand them out to the developers for further investigation. I'm still sure that the same will happen on Trunk. But I wasn't able to perform such an update on the customers computer yesterday. Lets see if I can do that within the next days in using a vmware image.

btw, since you're on windows, if you want to chase this, just setup quotas on an ntfs volume (preferably a small one, you can actually configure a removable flash volume for this <http://www.ntfs.com/quest22.htm>) and quota your user for the volume where you install+upgrade firefox.

Per Bug 498400 this can also lead to a loop

Wow, 4 Years now, this bug affects all versions and still is here? Is it also in 3.x versions?

Yes

Didn't know that it is soo difficult checking the diskspace before updating.

beltzner, if we are going to fix this for Android I think we should fix it for all apps so I threw together a quick string based on your previous suggestion. Though I don't like the term space for the regular UI I couldn't think of a better one and I think most users will understand what it means. I'll make it so the regular UI opens from the about window when this condition occurs.

Finally we install in space :-)

Carrying forward ui-review Dave, need these strings for b7

String pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/66c615aa68b9

Please note that we have now created a branch for beta 7 work. In addition to landing your fix on mozilla-central default, please also land it on mozilla-central GECKO20b7pre_20101006_RELBRANCH (note: when landing on mozilla-central default, you will be given priority in the landing queue at https://wiki.mozilla.org/LandingQueue )

Rob, how close are we to actually put these pre-landed strings into action?

The single pre-landed string will soon have code to drive it. The string's entity is already added to the xul so I don't think this should cause a problem for l10n anymore than any of the other strings that are only seen as the many other unusual error condition strings. Is there a concern regarding it for l10n?

Nope, just going through the list of open blocking [strings] bug and trying to get that count to 0. Helps to know that the string is only visible in edge-cases anyway, thanks.

At least the update doesn't break the installation anymore when disk space is low, but this still isn't handled satisfactorily. I know low disk space probably doesn't happen too often these days, but a fix should be pretty easy now I guess? It's just the error message that's wrong.

It still can if the timing is right. A fix isn't as simple as it would seem.

It's unlikely that I will get to work on this in the next two weeks, so unassigning myself for now.

July 2015 and this bug still hasn't been fixed :( It's a shame since otherwise Firefox has proved itself the best browser consistently for many years, and it's painful when this happens and I have to switch IE back on (grr) to reinstall Firefox. (fwiw the error msg was "...xul.dll is not a valid Windows image... please check against your installation diskette")

Wow! Is this an old bug or what? I used to get these occasionally but NOT for several years now. Thanks for your attention to this bug. George...