I made a very simple distribution, close to the original MS-DOS disks.
Main carachteristics:
- Single floppy
- Single language
- No fancy program or interface at all, but complete functionality
- Simple batch menu, with most functions are for partitioning, formating
and installing.
- Config optional with a supplied Congif+Autoexec containing a simple
but advanced setup.
I was making a new version, allong with required files for GPL
distribution, including a very good windows floppy generation executable
(I create it with a licenced program).
I just put it on wait for the new kernel. So far I found 2 BIG
advantages in the new kernel:
- Better SATA operation, at least in one machine only the new kernel worked
- better security: I use a database program and the new kernel rarely
has lost clusters after system crashes
I am glad to know that there is work on the new kernel's bug :)
Alain
Pat Villani escreveu:
Hello Alain,
I probably missed it. What is different about your distribution? f it
is a major imrpvement to what we have, why not distribute it as a
FreeDOS distribution?
Pat
On Thu, Jan 7, 2010 at 7:54 AM, Alain Mouette ala...@pobox.com
mailto:ala...@pobox.com wrote:
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
http://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 0x1, 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 $'
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 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
