Binaries started from FAT32, become corrupted, if booted from FAT32

[Valery V. Sedletski]

When playing with our Team Boot/2 bootable fat32 flash disk, I noticed the following problem: when I booted from a fat32 volume (usually, flash disk), and trying to start binaries like format.com, wget.exe, from the same FAT32 volume, I get the error like "The file format.com cannot be run in OS/2 session". If I look into the binary, I now see it being zeroed, if I view it in the hex viewer. But some binaries don't get corrupted, like shutdown.exe. I sometimes see that shutdown.exe fail to start, but after some number of attempts, it gets started, but didn't become corrupted. As it is known, the binaries are opened by the kernel Loader component, with read-write access, so it could be potentially overwritten, and it got really overwritten. What is interesting, I tried to start binaries from a non-bootable FAT32 medium, and I did not had any case when it got corrupted.

[Valery V. Sedletski]

Executable file corruption log

[Valery V. Sedletski]

This is fixed in r209. The problem was that, for some reason, when booted from FAT32 volume, and opening the executable file, two simultaneous opens are called almost at the same time. FS_OPENCREATE checks, if the file is opened for the 2nd time, and if so, then the starting cluster of the file is assigned from the previous open. If there are two simultaneous opens, then both opens see it opened for the 2nd time, and the cluster number is assigned uninitialized. So, after closing the file, the cluster in directory entry becomes invalid. Subsequent CHKDSK run results in a file with a zero content, and a file contents found in a lost cluster chain. Now I disabled this, and it seems to be fixed now.

See the updated r210 binaries in the usual place, at http://trac.netlabs.org/fat32/.

[Valery V. Sedletski]

Now it's fixed, so closing it.