Michael Devore wrote:
At 07:51 AM 7/26/2005 -0400, Mark wrote:

It is happening on multiple machines.  (Only one of which I have
access to). I suspect the large amount of free space on the drive, actually. I think that the divide by zero might actually be for

It appears to be correlated with large NTFS drives with lots of
free space.  Aren't there potential problems with files larger
than 4GB or more than 4GB free space?

Probably it, then. Several Bugzilla entries mention FDISK problems, including divide overflow, although I can't say if they correspond to what you're seeing. I don't have a visible NTFS partition when I run FreeDOS, so cannot test or comment further on the issue.

Hi Michael:

I've looked at the dir.c code from FreeCOM. I even duplicated
the problem on WindowsXP...the calculation underflows to zero
if you get a weird return from option 0x7303 on int21,
specifically a ridiculously large value for
FAT32_Free_Space.sectors_per_cluster (or, possibly,
FAT32_Free_Space.bytes_per_sector).  I really didn't expect
good data from WindowsXP. :-)

It is well behaved on this computer under FreeDOS, so I will
try it when I get home. I also ported the relevant code to
OpenWATCOM, so I have a simple test case.

This is what happened to "fail" under WindowsXP. Runs fine
under FreeDOS.

The "suspicious" portion is (from dir.c):

clustersize = FAT32_Free_Space.sectors_per_cluster
             * FAT32_Free_Space.bytes_per_sector;
[...]  FAT32_Free_Space.free_clusters / ((1024l*1024) / clustersize)

which will cause a divide by zero if clustersize > 1M.

This could be reordered to

FAT32_Free_Space.free_clusters * (clustersize/(1024l*1024)

which would eliminate the potential underflow. Anyway, I'll
run my test case on the problematic computer and see what
I find out. I hope it is this simple.

The displayString (which ultimately calls vfprintf) appears to have
enough space to handle a drive up to 99 GB free space and usually
calling printf with too small a field descriptor (%15s from
english.lng) doesn't cause a divide by zero error anyway, so
I'd guess that vprintf wouldn't either...


SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Freedos-user mailing list

Reply via email to