Re: [Freedos-devel] kernel 4GB fix, was release MOVE 3.4 WAS: Re: XCOPY 1.7 Stack Overflow

[Bernd B. <ber...@bo...>]

I have now adapted (not committed yet) the EDR kernel to mimic the behavior of Toms findings regarding the WIN10 DOSBOX. The write now fails as a whole if file size would exceed 4G-1 byte. The output of test4g.exe from my updated EDR kernel can be found at [1] (sorry, .png file).

@Tom, any explanation why in your results.txt the file offsets are different between WATCOM and MSVC? The offsets reported by the MSVC FAT32 seem to correspond with the source you provided. Did you alter the source in between? If not, something strange is going on...

Under my WATCOM 1.9 build of test4g the offsets are equal to your MSVC FAT32 build.

1: https://nextcloud.iww.rwth-aachen.de/index.php/s/ZcDX9tFcDyTescs

Bernd

> Am 29.03.2025 um 20:53 schrieb tom ehlert via Freedos-devel <fre...@li...>:
> 
> 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 <fre...@li...>:
>>> 
>>> 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
>>> Fre...@li...
>>> https://lists.sourceforge.net/lists/listinfo/freedos-devel
> 
> 
> 
> 
>> _______________________________________________
>> Freedos-devel mailing list
>> Fre...@li...
>> 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
> Fre...@li...
> https://lists.sourceforge.net/lists/listinfo/freedos-devel