Closed Bug 52037 Opened 24 years ago Closed 16 years ago

Confusing dialog overestimates space required, stops install

Categories

(SeaMonkey :: Installer, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: timeless, Unassigned)

References

()

Details

(Whiteboard: [xpibug][dogfood-] [ADT3])

Attachments

(1 obsolete file)

From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (Windows NT 5.0; U) BuildID: ? probably all recent installer builds. I don't use installer. <title>Disk space check</title> <body><p>Setup has detected insufficient disk space to continue with installation process on D: for the path:</p> D:\ <li>Required: 94121K</li> <li>Available: 80636K</li> <p>Click OK to go back and choose a different destination path, or click Cancel to cancel Setup.</p></body> OK or Cancel? OK means go back? Cancel means quit? Please change the buttons. "Go Back" and "Abort" make some sense. OK is not OK. Reproducible: Always Steps to Reproduce: 1. Try to run the installer so that it thinks you need 94121K when you only have 80636K 2. Don't select Mail & News or Chatzilla 2a. Total Download Size: 5569K Space Available: D: - 80636K 3. Click Next until you get the dialog. Actual Results: Lot's of problems: I get a dialog that says Mozilla needs 90MB to install a 6MB package I get a dialog that says if I think it's ok that it can't fit 6MB into 90 it will let me go back and change something. Expected Results: Don't confuse the math. Don't confuse the user. In English, I shouldn't have gotten this dialog in this case because I have sufficient free space. The dialog should have intuitive buttons. Disk is 4GB fat32 There are 78.7MB available. mozilla-win32-talkback.zip's expand nicely into this drive. As of windows2000 there are submounts aka Junction points. So even if f:\ has 1byte free, f:\bin might have 100MB free. The installer should not make these assumptions. This might become a tracking bug for at least 3 problems described here. I'm sorry, but it's only one installer and I never use it. - I mentioned in another bug that the correct solution is to use MSI, this is still the only correct solution. Fixing our installer is an acceptable workaround. MS once wanted to say that would make your product inelligible for 2000 seal of approval - I think they backed off [I'm a bit disappointed].
For starters: * `Disk Space Check' --> `Mozilla Installer' * `Setup has detected insufficient disk space to continue with installation process on D: for the path: D:\ Required: 94121K Available: 80636K' --> `{package name} cannot be installed in "{path}", because there is not enough disk space (94121 K required, 80636 K available).' * `Click OK to go back and choose a different destination path, or click Cancel to cancel Setup.' --> `Make more space available on the disk and try again, or try installing in a different location.' * [ Ok ] [ Cancel ] --> [ Retry ] [ Location ... ] [ Cancel ]
The "wierd math" you are seeing is because the size reported is download size, but it checks the "on disk" space required. The ~3500 chrome files we have chew up a ton of space on a FAT drive (should be fixed by archived chrome). This is admittedly confusing. We need to show both sizes somehow. Your point about win2k junction points is a good one. In XPInstall proper we use nsIFile to check the space available for a given path because unix supports the same concept. No telling if the nsLocalFileWin.cpp implements this correctly, though, and we probably don't do this in the native win installer either.
Ah, that almost makes sense. This drive is Fat32, and there were 10 other mozilla installs, sum total: 300MB. I also have NTFS drives which default to compressing files. And some Fat drives use drivespace or similar magic. Guessing that i needed 90mb for this install should be rethought. Such precise figures that are precisely off... Assuming we land jars this becomes a non issue. In the meantime, i'd almost like to have the option of "Install Anyways, the space will be there"
*** Bug 52038 has been marked as a duplicate of this bug. ***
Depends on: 52052
I can no longer do QA because the installer says I need about 10 times more disk space than it actually uses when it has finished installing, and I don't have enough room on my disk to let the installer finish installing. This is on Windows 2000, where I'm pretty sure we are using jars now...
Severity: normal → blocker
Keywords: dogfood
Found out we calculated the size required by a FAT drive as a "worst case" thing, and then asked everyone to have that much space. Ick. Now that we have chrome jars the difference between worst case and actual FAT32 should not be that large, certainly not a 10x difference. (Note that there is install overhead: the install engine is unpacked into a temp directory, and you have the 6Mb of downloaded .xpi files in addition to the final files before the cleanup runs. We *will* ask for more than the final files require). I can't approve dogfood bugs. By not nominating it for nsbeta3 are you saying you don't think it needs to be fixed by then?
Keywords: nsbeta3, rtm
I don't think we can make everyone happy here, but we shouldn't overestimate the space required by 10x and then not allow people to continue. Needs investigation for what quick fix we can provide and then remaining problems will have to wait for a future release.
Summary: Disk Space Check; Dialog is confusing → Confusing dialog overestimates space required, stops install
Whiteboard: [nsbeta3+]
This problem should not stop dogfood use, but should, as pointed out by dveditz, be looked at. Marking dogfood-minus
Whiteboard: [nsbeta3+] → [nsbeta3+][dogfood-]
I am looking into this.
Status: NEW → ASSIGNED
BTW, I'm using NTFS not FAT.
Too late for even a "quick fix" in PR3 (especially one likely involving a localization/text change to the warning dialog used).
Whiteboard: [nsbeta3+][dogfood-] → [nsbeta3-][dogfood-][rtm+]
Marking "needinfo." Will reconsider for inclusion once there is a reviewed and super reviewed patch.
Whiteboard: [nsbeta3-][dogfood-][rtm+] → [nsbeta3-][dogfood-][rtm+ need info]
Sean, is this basically the same as bugscape 2778, which you have a fix for? Or are you leaving this one open for the dialog itself, not the space overestimation? Didn't think we could get non-killer dialog changes approved. Most people will have enough space and not encounter this situation, so I'm leaning toward an [rtm-] due to general swampedness (the team is currently dealing with 24 rtm-ish bugs when we should be at about 4-5).
You are correct. This bug is not the same as bugscape 2778. I am intending on leaving this open for the requested dialog changes. Bugscape 2778 fixes the internal mechanism of calculating disk space. agh, I think I should have filed the other bug in bugzilla instead of bugscape.
We're fixing the over-estimation problem (bugscape 2778) but will not be able to fix the dialog for RTM.
Whiteboard: [nsbeta3-][dogfood-][rtm+ need info] → [nsbeta3-][dogfood-][rtm-]
fyi: the other bug takes into account NT5 mount points (Reparse Tags/Points) and user quotas when fixed.
Keywords: nsbeta1
Whiteboard: [nsbeta3-][dogfood-][rtm-] → [xpibug][nsbeta3-][dogfood-][rtm-]
Keywords: nsbeta3, rtm
Whiteboard: [xpibug][nsbeta3-][dogfood-][rtm-] → [xpibug][dogfood-]
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9
Keywords: dogfood, nsbeta1nsbeta1+
QA Contact: gemal → gbush
In MacInstaller build 2001031608, the numbers that appear in the dialog are mixed up. Something like: Space required:670k Available space:27000k
Target Milestone: mozilla0.9 → mozilla0.9.1
no longer a blocker.
Severity: blocker → normal
Unless I'm misunderstanding this bug is now a dialog change. We're past the localization cut-off for this milestone.
Keywords: nsbeta1+nsbeta1-
Target Milestone: mozilla0.9.1 → ---
No longer depends on: 52052
reassign
Assignee: ssu → syd
Status: ASSIGNED → NEW
Keywords: nsbeta1-nsbeta1
Blocks: 104166
Keywords: nsbeta1
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9.8
reassigning to dprice
Assignee: syd → dprice
Severity: normal → major
Keywords: nsbeta1
Priority: P3 → P2
dprice is on sabitcal. moving to next milestone.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Keywords: patch
Target Milestone: mozilla0.9.9 → mozilla1.0
could i please have a review??
Sean, Doug: Could I get a r= for this patch?
Comment on attachment 42020 [details] [diff] [review] f:\programf\dev != f:\ requires w95osr2 or better. sr=dveditz
Attachment #42020 - Flags: superreview+
Comment on attachment 42020 [details] [diff] [review] f:\programf\dev != f:\ requires w95osr2 or better. r=dougt.
Attachment #42020 - Flags: review+
Timeless: do you have check-in privs, or do you want me to do it?
Comment on attachment 42020 [details] [diff] [review] f:\programf\dev != f:\ requires w95osr2 or better. Patch committed. The rest of the concerns raised by this bug still need to be addressed.
Attachment #42020 - Attachment is obsolete: true
This is more of a stub installer thing now since timeless fixed the engine problem. Over to curt to see if it fits in with the bugs he's currently working on.
Assignee: dprice → curt
ADT3 per ADT/XPInstall triage.
Whiteboard: [xpibug][dogfood-] → [xpibug][dogfood-] [ADT3]
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt. If you have any questions about this, please email adt@netscape.com. You can search for "changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
*** Bug 161219 has been marked as a duplicate of this bug. ***
retargeting
Target Milestone: mozilla1.0 → Future
Product: Browser → Seamonkey
Assignee: curt → nobody
Priority: P2 → --
QA Contact: agracebush → general
Target Milestone: Future → ---
Seamonkey and Firefox are using a new NSIS based installer. resolving this old bug, please reopen if you still get this with the new installer
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: