Hi! I am also working on this for the EDR-DOS kernel. I made FAT+ support a build time option, disabling it by default. It previously was included unconditionally and enabled for every partition. I consider this dangerous, as the EDR-DOS kernel is the only one supporting this, and chances of data corruption are high when accessing a file >2^32-1 bytes with an operating system other than EDR-DOS.
However, the EDR kernel had no provision of disallowing writes if the file grows too large. So I made an initial implementation like this: - When writing to a file, write only the number of bytes so that the file size does grow beyond 2^32-1 bytes. - If this leads to bytes written = 0 then return with carry set and DOS error code 5 (access denied), otherwise succeed and return the number of bytes actually written. This makes sure that the file can grow to exactly 2^32-1 bytes and not 2^32-x, where x depends on the last (and failing) write operation. Error code 5 seems to be used in a similar situation according to RBIL [1]. But I am not sure if it a good error code for it. Side note: I discovered a critical bug in the EDR kernel regarding deletion of LFN directory entries. The kernel would delete wrong directory entries then the LFN entries of a file cross a cluster boundary. Bug exists since at least Udo Kuhnts last 7.08 WIP kernel. So BE CAREFUL when accessing file systems containing LFNs with these kernels. The commit [2] seems to have fixed the issue. 1: https://fd.lod.bz/rbil/interrup/dos_kernel/2140.html 2: https://github.com/SvarDOS/edrdos/commit/450757f2c7407181af03c891db15aec39c2cd64f Bernd > Am 28.03.2025 um 18:38 schrieb tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > Hallo Herr tom ehlert via Freedos-devel, > > am Donnerstag, 27. März 2025 um 17:56 schrieben Sie: > >> Hallo Herr Fritz Mueller via Freedos-devel, > >> am Donnerstag, 27. März 2025 um 17:51 schrieben Sie: > >>> thanks, I already tested it, also works fine. so only the copy command is >>> over for the moment, but I will have to test if it is already fixed or not >>> (i already reported anywhere at git that 3 files with 1,6 gb and copy a +b >>> +c 4 gb creates a 4gb file where the rest of file c is written to the >>> beginning of a on the 4gb file). but this is a thing that should rarely >>> happen and can be fixed with the next kernel/command.com. > >> it's a kernel bug. > >> I will post a fix tomorrow. > > as promised, the fix for the overflow at 4GB should be > > > ... > fnode_to_sft(fnp); > return 0; > } > >>>>>>>>>>>>> > FATFS.C, line 1248 > > /* TE 26 feb 2025 : prevent overflow at 4G. > how do I proper return 0 bytes written, error = DE_HNDLDSKFULL > ? > */ > if (fnp->f_offset + count < fnp->f_offset) // overflow > { > if (mode == XFR_WRITE) > { /* can't extend beyond 4G > return > '0 byte written, DISK_FULL > */ > return DE_HNDLDSKFULL; > } > else { /* XFR_READ should end automatically at EOF > */ > } > } > > <<<<<<<<<< > > > > > /* The variable secsize will be used later. */ > secsize = fnp->f_dpb->dpb_secsize; > .... > > Tom > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
