[Fedora-directory-commits] setuputil/installer/unix product.cc, 1.3, 1.4

[Nathan Kinder (nkinder)]

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);