## Host environment - Operating system: Windows 11 Pro 24H2 - Architecture: x86_64 - QEMU flavor: qemu-system-i386 - QEMU version: 11.1.0 (v11.1.0-12130-ge470268ff4) - QEMU command line: `-M isapc -cpu 486 -m 16 -fda <dos boot floppy> -drive file=fat:rw:<hostdir>,format=raw,if=ide,index=0 -boot a -display none` ## Emulated environment - Operating system: MS-DOS 6.22 - Architecture: x86 real mode ## Description of problem On a `fat:rw:` share, a file written by the guest and read back by the guest returns zeroes for every complete 512-byte sector. Only the trailing partial sector survives. No error is reported to the guest at any point: the write succeeds, the file has the right length in the directory, and the read succeeds and returns the wrong bytes. The rule is exact, and it is the file's SIZE that decides, not how it was written. A 100-byte file is fine. A 512-byte file comes back as 512 zeroes. A 2047-byte file comes back as 1536 zeroes followed by the correct last 511 bytes. I first assumed this was buffered stdio flushes going missing, but writing in 4096-byte blocks (which bypasses the C runtime's buffer) fails identically to writing in 512-byte blocks. It tracks the file size alone. ## Steps to reproduce Compile the program below for 16-bit DOS and run it on a `fat:rw:` drive. It writes a file, closes it, reopens it, reads it back and compares against the pattern it wrote. It needs nothing but the C library, no network and no other software. ```c #include <stdio.h> static const unsigned SIZES[] = { 100, 511, 512, 513, 1024, 2047, 4096 }; static unsigned char pat(unsigned long i) { unsigned char c = (unsigned char)((i * 7UL + 3UL) & 0xFFUL); if (c == 0x00) c = 0x55; /* never zero, so lost data is obvious */ if (c == 0x1A) c = 0x56; /* never DOS EOF */ return c; } static int one(const char *path, unsigned size, unsigned wchunk) { static unsigned char buf[4096]; FILE *f; unsigned i, off, n, bad = 0, nul = 0; long got = 0; f = fopen(path, "wb"); if (!f) return 1; for (off = 0; off < size; off += n) { n = (size - off < wchunk) ? (size - off) : wchunk; for (i = 0; i < n; i++) buf[i] = pat((unsigned long)off + i); fwrite(buf, 1, n, f); } fclose(f); f = fopen(path, "rb"); if (!f) return 1; for (;;) { n = (unsigned)fread(buf, 1, sizeof(buf), f); if (n == 0) break; for (i = 0; i < n; i++) { unsigned long a = (unsigned long)got + i; if (buf[i] != pat(a)) { bad++; if (buf[i] == 0 && nul == a) nul++; } } got += n; } fclose(f); if (got != (long)size || bad) { printf("%u/%u len=%ld bad=%u leading_nul=%u\n", size, wchunk, got, bad, nul); return 1; } return 0; } int main(void) { int s, fails = 0; for (s = 0; s < 7; s++) fails += one("C:\\FSTEST.$$$", SIZES[s], 512); for (s = 0; s < 7; s++) fails += one("C:\\FSTEST.$$$", SIZES[s], 4096); remove("C:\\FSTEST.$$$"); printf("fails=%d\n", fails); return fails; } ``` On a `fat:rw:` drive it prints `fails=10`: ``` 512/512 len=512 bad=512 leading_nul=512 513/512 len=513 bad=512 leading_nul=512 1024/512 len=1024 bad=1024 leading_nul=1024 2047/512 len=2047 bad=1536 leading_nul=1536 4096/512 len=4096 bad=4096 leading_nul=4096 512/4096 len=512 bad=512 leading_nul=512 513/4096 len=513 bad=512 leading_nul=512 1024/4096 len=1024 bad=1024 leading_nul=1024 2047/4096 len=2047 bad=1536 leading_nul=1536 4096/4096 len=4096 bad=4096 leading_nul=4096 fails=10 ``` Same binary, same guest, same QEMU, with the only change being a real FAT16 disk image instead of the vvfat share (`-drive file=disk.img,format=raw,if=none,id=hd0 -device ide-hd,drive=hd0`): `fails=0`. Every size passes, both write chunk sizes. ## A second symptom, possibly the same cause While looking at the host side of the share I found two distinct guest files mapped onto one host file. The guest had written `C:\FSTEST.$$$` (the temp file above, which the program deletes before exiting) and separately `C:\HELMOUT.TMP`. Afterwards the host directory contained a 379-byte `fstest.$$$` whose contents were the text that the guest had written to `HELMOUT.TMP`, and no `HELMOUT.TMP` at all. That looks like a cross-link in the directory mapping rather than dropped data, and it would explain reads returning another file's clusters, or zeroes where a mapping points at nothing. Not all guest writes are affected. Files written and then renamed into place came back byte-perfect on the host, verified by SHA-256 against what was sent, including a 64 KB one. I have not worked out what distinguishes those from the ones that come back as zeroes. ## Why this seems worth reporting despite the beta status The documentation is clear that vvfat read/write is for testing and to be used at your own risk, and I am not asking for a guarantee it does not offer. The specific thing that seems worth flagging is that the failure mode is a silent wrong answer rather than an error or a refusal. "Use at your own risk" reads as a warning that you might lose data. Here the guest writes data, gets no error, reads it back, gets no error, and receives zeroes. Anything using such a share to carry measurements or test output will believe it. In my case every command output over 511 bytes had been quietly wrong for some time before I noticed, because nothing had asserted on the content of a long output. If a fix is out of scope for a beta driver, a note in the documentation that reads of guest-written files can return zeroes, rather than only that writes may be lost, would have saved me a lot of time. ## Additional information Related: issue #2786 (deleting files fails on vvfat) reproduces on this same setup, and I have added a deterministic reproducer there. I do not know whether the two share a cause.