Closed
Bug 59322
Opened 24 years ago
Closed 23 years ago
XPInstall fails on JRE: miscalculates available disk space
Categories
(Core Graveyard :: Installer: XPInstall Engine, defect, P1)
Tracking
(Not tracked)
mozilla0.9.9
People
(Reporter: dr, Assigned: dprice)
References
Details
from install.log: ------------------------------------------------------------------------------- file:///tmp/.tmp.xi.0/bin/../jre.xpi -- 11/06/2000 19:45:35 ------------------------------------------------------------------------------- Sun Java 2 ---------- ** initInstall: 0 ** plugins folder: /home/dr/ns6/plugins/ ** Insufficient disk space: /home/dr/ns6/plugins/ ** required : 40098 K ** available: 27000 K Install **FAILED** with error -235 I'm guessing that this is either a problem with nsIFile or with the fact that my machine is running Redhat 7 (which has given me endless trouble...). I have 4 gigabytes of space available in my /home partition, with no quotas on that filesystem or anything. See: dr@midget ~ -> df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda5 5045104 568092 4220732 12% /home This appears to be misread by the installer as 27 megs.
Comment 2•24 years ago
|
||
Assessed as not a stop-ship bug because this showed up on a RH 7 system only so far (although it is theoretically a bug on lower kernel revs too but there is insufficient empirical evidence to confirm the latter). Must be fixed by next release. Needs more investigation.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Updated•24 years ago
|
Priority: P3 → P1
Nominating.
Naw, I bet the installer is looking for space in TMPDIR which is probably filled up or too small on your system... hrmmm, this happened over a year ago (boy, we are quick to respond, eh? :-) probably can ask for a full du -k output at this point?
Assignee: syd → curt
Keywords: nsbeta1
I think we need to address this one. I don't know in what time frame, but I keep hearing about this type of problem every now and then.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
reassigning to dprice. nsIFile may be returning bogus values on large drives, some kind of overflow problem perhaps?
Assignee | ||
Comment 9•23 years ago
|
||
What version of redhat are you using? I'm testing on redhet 7.1 and I'm not seeing it. I wrote a simple script that calls our File.diskSpaceAvailable and it produces the following output: ------------------------------------------------------------------------------- file:///home/dprice/avail.xpi -- 02/20/2002 19:37:48 ------------------------------------------------------------------------------- Functional: diskSpaceAvailable ------------------------------ ** File.diskSpaceAvailable reports 8363941888 Install completed successfully Finished Installation 02/20/2002 19:37:48 This is consistant with the output from df 7:37pm dp @h-10-169-103-115/export/60Trunk/mozilla/dist/bin > df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/hdb1 5044156 1271392 3516532 27% / /dev/hdb5 10080488 1400504 8167916 15% /export
Comment 10•23 years ago
|
||
This was fixed with revision 1.44 of nsLocalFileUnix.cpp on 2001/04/18, checked in by me as it turns out (old code had dodgy long long usage). *** This bug has been marked as a duplicate of 71393 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•