Good theory, I wouldn't have expected that as the text processing isn't included in the file handing but as a point I testedNice, gzip is a good choice for compatibility.
0x08 turned out to be ASCII backspace, so there may be some kind of incomplete text handling stuff in fputc...
Code:
fputc(0x1f, fout); fputc(0x8b, fout); fputc(0x09, fout); // Change to 0x09 test if we over write last byte. fputc(0x00, fout); // FLGSome more investigation. when writing 0x8b to the file we return EOF I checked and I think it's a bug in the UNICODE support I've swiched to this option to 0 from 2 and now it's working.
Code:
#define FF_LFN_UNICODE0/* This option switches the character encoding on the API when LFN is enabled.// 0: ANSI/OEM in current CP (TCHAR = char)/ 1: Unicode in UTF-16 (TCHAR = WCHAR)/ 2: Unicode in UTF-8 (TCHAR = char)/ 3: Unicode in UTF-32 (TCHAR = DWORD)// Also behavior of string I/O functions will be affected by this option./ When LFN is not enabled, this option has no effect. */Statistics: Posted by DarkElvenAngel — Tue Mar 25, 2025 7:10 pm