Author: nkinder
Update of /cvs/dirsec/setuputil/installer/unix
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv29367
Modified Files:
product.cc
Log Message:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182611
Bug(s) fixed: 182611
Bug Description: When running setup of 64-bit Directory Server on my FC4 x86_64 machine,
setup complains that there is not enough available diskspace when I actually have 90+
GB
available on the installation partition.
Reviewed by:
Files: see diffs
Branch: HEAD (setuputil)
Fix Description: We were using fscanf to read in the total unzipped size of our zip
archives
incorrectly. It was scanning for a normal int, but storing it in a long. The
compiler was
not automatically converting types correctly which would cause the required space to
be
a huge number. The proper thing to do is to have fscanf read in a long.
Flag Day: no
Doc impact: no
QA impact: Should be covered by manual and nightly testing
New Tests integrated into TET: none
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=125120
Index: product.cc
===================================================================
RCS file: /cvs/dirsec/setuputil/installer/unix/product.cc,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- product.cc 12 Jan 2006 17:26:46 -0000 1.3
+++ product.cc 23 Feb 2006 17:57:02 -0000 1.4
@@ -27,6 +27,25 @@
**
** HISTORY:
** $Log$
+** Revision 1.4 2006/02/23 17:57:02 nkinder
+**
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182611
+** Bug(s) fixed: 182611
+** Bug Description: When running setup of 64-bit Directory Server on my FC4 x86_64
machine,
+** setup complains that there is not enough available diskspace when I actually have
90+ GB
+** available on the installation partition.
+** Reviewed by:
+** Files: see diffs
+** Branch: HEAD (setuputil)
+** Fix Description: We were using fscanf to read in the total unzipped size of our zip
archives
+** incorrectly. It was scanning for a normal int, but storing it in a long. The
compiler was
+** not automatically converting types correctly which would cause the required space
to be
+** a huge number. The proper thing to do is to have fscanf read in a long.
+** Flag Day: no
+** Doc impact: no
+** QA impact: Should be covered by manual and nightly testing
+** New Tests integrated into TET: none
+**
https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=125120
+**
** Revision 1.3 2006/01/12 17:26:46 nkinder
** 174749 - Uninstall should not follow symlinks
**
@@ -1160,7 +1179,7 @@
if (fp = fopen(tmpfilename.data(), "r"))
{
long size;
- if (EOF != fscanf(fp, "%d", &size))
+ if (EOF != fscanf(fp, "%ld", &size))
{
long newSize = getArchiveSize() + (size / 1024 + 1);
setArchiveSize(newSize);
@@ -1228,7 +1247,7 @@
if (fp = fopen(tmpfilename.data(), "r"))
{
long size;
- if (EOF != fscanf(fp, "%d", &size))
+ if (EOF != fscanf(fp, "%ld", &size))
{
long newSize = getArchiveSize() + (size / 1024 + 1);
setArchiveSize(newSize);