Thanks for the test case, Tom! This seems to fail hard under the EDR kernel (does not terminate, and kernel allocates all clusters). The EDR code indicates that the initial number of clusters allocated for the first write may not exceed 16-bit:
https://github.com/SvarDOS/edrdos/blob/4e432873aab92f26d6043549a6eb87a7c6c11fdb/drdos/bdevio.asm#L946 So this may be a problem when the initial write is at offset 0x80000000-50. I think fdwrite_extend would have to be altered to make this work, but have to run it under the debugger to be sure. Interestingly the code path linked above is only taken if there are no clusters at all already allocated. A few lines above there is a 32-bit path if there is at least one cluster already allocated. https://github.com/SvarDOS/edrdos/blob/4e432873aab92f26d6043549a6eb87a7c6c11fdb/drdos/bdevio.asm#L920 I am wondering if it would work if a single byte is written at the start of the file prior to the seek. Will have to do some testing… Bernd > Am 29.03.2025 um 20:53 schrieb tom ehlert via Freedos-devel > <freedos-devel@lists.sourceforge.net>: > > Hi, > > I did some experiments on this IN THE WIN10 DOSBOX which is usually > a very good approximation for MSDOS behaviour (I had no MSDOS at hand). > > the result is that > > on a FAT32 drive, the write that would go beyond 4GB is aborted, with "disk > full" > > on a NTFS drive, the drive succeeds, but DOS programs are later not allowed > to open it. > > results for MSVC win32 and watcom are very similar, see results.txt > > the attached .SVP is a .ZIP > > IMO my first approximation was correct. > > > > Tom > > > > > am Freitag, 28. März 2025 um 23:05 schrieben Sie: > >> 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 > > > > > > Mit freundlichen Grüßen / with kind regards > Tom Ehlert > +49-15151898538<test4g.svp>_______________________________________________ > 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
