mirror of https://github.com/FDOS/kernel.git
Remove obsolete file relnotes.txt
git-svn-id: https://svn.code.sf.net/p/freedos/svn/kernel/trunk@531 6ac86273-5f31-0410-b378-82cca8765d1b
This commit is contained in:
Bart Oldeman
parent
080d1dd883
commit
faf982adc1
|
|
@ -1,177 +0,0 @@
|
|||
Release notes for kernel 2024d and its development predecessors
|
||||
2024BL,M,N: we think that by now we have ironed out most of these
|
||||
bugs, but be careful nonetheless.
|
||||
|
||||
About KE2024BL:
|
||||
|
||||
*********************************************************
|
||||
* *
|
||||
* THIS IS A BETA RELEASE *
|
||||
* *
|
||||
* BE CAREFUL *
|
||||
* *
|
||||
* SAVE YOUR DATA. SAVE OFTEN. *
|
||||
* *
|
||||
* THIS RELEASE MAY DESTROY YOUR DISK COMPLETELY *
|
||||
* *
|
||||
*********************************************************
|
||||
|
||||
|
||||
KE2024BL introduced full LBA support; i.e. disk may be up to
|
||||
2^32 * 512 bytes = 2000 GB large.
|
||||
|
||||
also new is the working of 64K FAT clustersize for a max
|
||||
logical disksize of 2^16 * 64K = ~4 GB.
|
||||
|
||||
KE2024BM is its follower, with some more bugfixes.
|
||||
|
||||
|
||||
How dangerous is it?
|
||||
|
||||
The KE2024BL kernel has been send by private mail to some of us,
|
||||
has been tested on 7 maschines with and without LBA support.
|
||||
|
||||
No errors (other then the known bugs) were reported.
|
||||
And KE2024BM is pretty conservativ, before it accepts and uses
|
||||
a disk.
|
||||
|
||||
the main problem may be, that a disk recognized by an older
|
||||
kernel, will no longer work with the new one, because strange
|
||||
partitioning scemes, although nothing like that has been reported.
|
||||
|
||||
So, if after booting you see all your drives, containing resonable
|
||||
data, it should be pretty save to use.
|
||||
|
||||
Be a bit careful, nevertheless.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
full LBA support and 64K FAT clustersize for a max
|
||||
logical disksize of 2^16 * 64K = ~4 GB
|
||||
|
||||
|
||||
were have been tested in the following way:
|
||||
|
||||
on my 30GB disk, a partition with 1.7 GB for 32K clusters and
|
||||
3.5 GB for 64K clusters created. the 3.5 GB partition was created,
|
||||
using Win2K.
|
||||
|
||||
my WINNT directory (~350MB) was copied there - (using VC)
|
||||
once for 32K,
|
||||
for 64K,
|
||||
xcopy c:\WINNT j:\WINNT /s
|
||||
xcopy j:\WINNT j:\WINN1 /s
|
||||
xcopy j:\WINN1 j:\WINN2 /s
|
||||
xcopy j:\WINN2 j:\WINN3 /s
|
||||
xcopy j:\WINN3 j:\WINN4 /s
|
||||
to fill the disk.
|
||||
|
||||
|
||||
the 350 MB files (WINNT for 32K, WINN4 for 64K) were then
|
||||
compared to the original file. they were identical.
|
||||
|
||||
no, not all files were copied due to restrictions in MAX_PATH_SIZE,
|
||||
but the files, that were copied, compared ok.
|
||||
|
||||
the files were also readable with WinNT, and they were identical, too.
|
||||
WinNT chkdsk was content with the disk.
|
||||
|
||||
|
||||
next, the kernel source was copied to this drive, compiled,
|
||||
and verified.
|
||||
|
||||
so, it _seems_ to work for me.
|
||||
|
||||
known issues:
|
||||
* VC will say, that the disk has size of 0 byte, with 0 byte free.
|
||||
this is not a kernel bug.
|
||||
VC simply multiplies BytesPerSec*SecPerCluster, gets
|
||||
128*512 = 0x10000, and saves the low part, which is 0.
|
||||
|
||||
* the behaviour for filesize at or above 2GB (where the sign
|
||||
gets negative) is completely untested. test it, if you like
|
||||
|
||||
* there are some bugs, when the pathlength is around 64.
|
||||
this may lead to incontinent (sorry, inconsistent) behaviour,
|
||||
like
|
||||
you can MKDIR a directory, but not CHDIR to it
|
||||
and similiar things.
|
||||
some of them found and removed, but there are probably more
|
||||
to be found yet. fortunately, none lead to data loss :-)
|
||||
|
||||
|
||||
*********************************************************
|
||||
* *
|
||||
* BE CAREFUL *
|
||||
* AND SAVE YOUR DATA. SAVE OFTEN. *
|
||||
* *
|
||||
*********************************************************
|
||||
|
||||
|
||||
Bugs and fixes in the FAT filesystem (tested on KE2024BN)
|
||||
|
||||
---------------------------------------------------------
|
||||
KE2024BM:
|
||||
Disk Full not detected in a compatible way.
|
||||
it was possible to create a directory(pointing to nowhere),
|
||||
even if disk was full.
|
||||
|
||||
---------------------------------------------------------
|
||||
DosGetFreeSpace is wrong (verified on KE2022, too):
|
||||
|
||||
when creating files, the 2nd and following clusters are
|
||||
counted twice when created.
|
||||
|
||||
simply copy one file to another, delete 2nd file;
|
||||
watch free space before and after.
|
||||
corrected in KE2024BP
|
||||
|
||||
---------------------------------------------------------
|
||||
#include <stdio.h>
|
||||
#include <io.h>
|
||||
main()
|
||||
{
|
||||
FILE *fd = fopen("test.dat","w");
|
||||
int fdn = fileno(fd);
|
||||
|
||||
lseek(fdn,10000,SEEK_CUR);
|
||||
write(fdn,"hello world",10);
|
||||
}
|
||||
|
||||
creates file of DirSize 10010 bytes, but reserves
|
||||
a single FAT entry cluster
|
||||
|
||||
this is obviously nonsense.
|
||||
|
||||
and there is no "hello world" in it :-(
|
||||
|
||||
cured by FATFS.C,
|
||||
/* Now that we've found a free FAT entry, mark it as the last */
|
||||
/* entry and save it. */
|
||||
/* BUG!! this caused wrong allocation, if file was created,
|
||||
then seeked, then written */
|
||||
+ fnp->f_cluster =
|
||||
fnp->f_dir.dir_start = free_fat;
|
||||
|
||||
|
||||
|
||||
|
||||
--------------------------------------------------------------
|
||||
when a big file is created, and cut afterward, the filespace is NOT freed
|
||||
try:
|
||||
copy command.com xx
|
||||
dir
|
||||
echo >xx
|
||||
dir
|
||||
and compare disk free info.
|
||||
the space is freed, however, if xx is deleted after that.
|
||||
--------------------------------------------------------------
|
||||
|
||||
|
||||
|
||||
|
||||
regards
|
||||
tom ehlert (tom.ehlert@ginko.de)
|
||||
Loading…
Reference in New Issue