Good day, all:
I believe I have found a bug in FreeCOM's implementation of the
DIR command. This causes a Divide by zero error and forces a
reboot.
Using the DIR command on an NTFS4DOS mounted NTFS partition
which should show
0 File(s) 0 bytes
7 Dir(s) 69,704,994,816 bytes free
causes the error.
This appears to be due to the following code in FreeCOM's
dir.c, function dir_print_free. This from the CVS mirror download
http://www.fdos.org/kernel/freecom.HEAD.zip:
rootname[0] = toupper(*path);
r.r_ax = 0x7303;
r.r_ds = FP_SEG(rootname);
r.r_dx = FP_OFF(rootname);
r.r_es = FP_SEG(&FAT32_Free_Space);
r.r_di = FP_OFF(&FAT32_Free_Space);
r.r_cx = sizeof(FAT32_Free_Space);
intr(0x21, &r);
if(!(r.r_flags & 1)) {
dprintf(("[DIR: Using FAT32 info]\n"));
clustersize = FAT32_Free_Space.sectors_per_cluster
* FAT32_Free_Space.bytes_per_sector;
if(FAT32_Free_Space.free_clusters >= 0x8000000l / clustersize) {
convert(FAT32_Free_Space.free_clusters /
((1024l*1024) / clustersize), buffer);
strcat(buffer, " Mega");
goto output;
}
}
Specifically, the disk is reporting 64 sectors per cluster and
32768 bytes per sector. This makes ((1024l*1024)/clustersize)
evaluate to 0! This appears to be a relatively new change to
DIR.
I have duplicated this using a test program ported to
open Watcom on this same disk. That's the way I got the
results of the intr(0x21, &r) call. The same error does not
occur using MSDOS. It reports a disk size of " free bytes"
(yes, a blank).
This renders NTFS4DOS difficult to use on many modern
computers.
Mark
-------------------------------------------------------
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-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
