Disk space available is 102MB, Typical Installation proceeds through download, extraction and installation of seamonkey but fails at mail/news with -235 error, insufficient disk space. At this point there is still 49MB left on disk If I try custom installation, I am warned before installation starts that there is 120520k required and I only have 102816k on disk.

moving to M14

Too much footprint. Depends on creating an install-engine/XPCOM zippy (21426) and moving resources into jar files. The install team is only responsible for the first of these. Incidentally the "49Mb left on disk" is an illusion -- we definitely ran out and required the amount we said initially, but may have cleaned up temp files before you were able to check.

PDT+

We have recently broken out the core install engine, requiring less diskspace. That phantom 49Mb(!) went to the core install engine that was then deleted after the install failed, now the phantom space should be closer to 1Mb or so. This will not prevent people from running out of disk space of course, but I'm not sure we're really talking about a bug here. Sean says that if you are not running something that's also using up diskspace the bug is that we miscalculated the required space. Otherwise this is expected behavior.

I can't reproduce this, and Grace (who can reproduce this) has already left for the day. I need to see her get the error on her system. I would not consider this a PDT+ bug anymore since the big core.xpi has been split into two smaller ones. This aleviates the enourmous disk space required during installation by quite a bit.

I've done some more testing, and still could not reproduce it. The breaking up of core.xpi into core.xpi and browser.xpi might have just fixed this. Grace, I'll mark this as fixed. Please reopen if you're tests indicate it is still a problem.

Still able to reproduce- If I choose complete or custom (with talkback unchecked) - I am notified not enough disk space- both of those installs include java It appears that my disk space is right on the edge of 'enough/not enough'- I had to do this 3 times to get the error.

finally fixed it. The problem was with the FAT16 table. It appearently eats up one cluster size for each directory created. This has now been taken into account when calculating the disk space requirements during the wizard part so that each .xpi file does not complain with -235 anymore. I'm reassigning this to leaf and cc:'ing granrose because I know that their daily windows build system does not refresh nstools as part of the build procedure (this is not good). ds32.exe was updated as part of this fix, which resides in nstools/bin. Please update nstools on the daily windows build machine (or the install build scripts will fail in the morning), and this bug will definitely be fixed.

I've updated the win32 verification build machine. It pulled ds32.exe gmake.exe nsinstall.exe and shmdossomething.exe. Since it was still pulling mozilla at the time, this fix should show up in this morning's build.

this is fixed. I tested and got the usual warnings for complete and custom and this installed successfully.

gbush, just mark this verified, if you would.

done