Hi, I updated the source in SVN and the binary at http://dosemu.org/bart/kernel.sys with your bug (below) fixed. Thanks for the report.
I made 4 adjustments: 1. If there is no FSINFO sector, don't use it. 2. Range check the FSINFO values to make sure they are usable (that fixes the bug -- the DPB value for an unknown first free cluster is 0 (cf. RBIL, INT21/AH=53), not 0xFFFFFFFF and that confused things). 3. Since the FSINFO first free cluster value is just a hint, when searching for a free cluster the kernel now scans the whole FAT, just starting at the hint but wrapping around in case there is a free cluster before. 4. When calculating free space, we obtain the correct first free cluster almost for free. That speeds up step 6 in your report, which now succeeds. I noted that the FreeDOS kernel uses the FSINFO next free cluster value to mean the absolute first free cluster, but RBIL just says "cluster at which to start search when writing, usually the last cluster allocated", which is a lot weaker! Change 3 above accommodates this. bug: > * minor "can't-save-after-FSINFO-invalidation-BUG" > 0. Get FreeDOS kernel 2040 (see shot) > 1. Get a FAT28 volume with some free space > 2. Set both values in FSINFO to $FFFF'FFFF > 3. Reboot > 4. DIR > -- observed effect: takes centuries to peek the free space > 5. DIR > -- observed effect: no longer > 6. try to brew a file or subdirectory > -- observed effect: doesn't work (no problem in EDR-DOS) <<<--- BUG HERE > 7. try to brew a file or subdirectory > -- observed effect: no longer Bart ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
