Hi dos386 :-) > 1. No new details to the "Crosslink-BUG" ... cluster size is 4 KiB :-|
However, it is very interesting that it involves broken high 16 bits on FAT32 on almost full disks. I hope this helped Bart to zoom in on potential causes for the bug :-). http://sourceforge.net/support/tracker.php?aid=2901916 www.mail-archive.com/freedos-kernel%40lists.sourceforge.net/msg02431.html To summarize your 19 Dec 2009 mail: Use kernel 2039 on a FAT32 (FAT28) disk, for example 6 GB with 4 kB/cluster and quite full, for example 95 p/c, with fragmented free space. Copy some files, delete some, copy some more files. Then, you say, many cross-links show up, mostly in the freshly copied two sets of files, also lost cluster chains. You are very right that the INTERESTING thing is that the broken files all have bad starting cluster numbers, all below 0x10000, even though there were no free clusters in the first 65536 clusters before the experiment! > 2. Discovered a NEW BUG: Half of it is not a bug, the other half is... > 1. Get WDE or similar > 2. Overwrite both entries in FS-info sector with $FFFF'FFFF > 3. Reboot to FreeDOS > 4. DIR - there is a massive delay at the end This is because DIR tells you how much space is used / free. For that, DOS has to count all used / free FAT clusters by reading the whole FAT, which is big in FAT32. The FS-Info sector caches the information, but by setting the values to the FFFF which you mention, you force a recalculation... > 5. DIR - no delay anymore See above :-) > 6. Try to brew a file or SUBDIR ("MD") > - expected result: should work > - effective result: DOESN'T WORK Do you also get problems with file creation or growth, as far as those involve allocation of more clusters? If yes, which problems, just failure? Or creation of cross links? > 7. Retry and it will work now Interesting! > EDR-DOS doesn't have this bug. It probably also has the delay? I assume by bug you only mean the problem of creating a directory after invalidating FS-Info? Eric PS: I think 2039 got less publicity than 2038 and 2038 has more conservative updates. Combined, this means in 2039 you have more changes but (yet) fewer testers... ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
