Hi all, first of all, Happy ne year :)
Is there anyone working on, o willing to work on this cross-linked files bug? It seams to me that this can be very important for FreeDOS use, I allways assume that if a bug exists somewhere hidden, it could also atack under other circumstances, ie. not only on a 4Gb 99.9% full disk :( I have prepeared a new FreeDOS distribution for REAL USE in the field and this is holding me back. I never had problems with disks (older kernel), maybe even lass then with MS-DOS 7.10, and the latest kernel that I tested is even better (near to no lost cluster on reset). So this new version is very exciting :) Thanks for all, Alain Eric Auer escreveu: > 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
