Opened 2 years ago

Closed 22 months ago

#25 closed defect (fixed)

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

Reported by: valerius Owned by:
Priority: major Milestone: GA
Component: IFS Version: 1.0
Severity: medium Keywords: fat32 boot binarry corrupt fail start run


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, wget.exe, from the same FAT32 volume, I get the error like "The file 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.

Attachments (1)

fat32.log (32.9 KB) - added by valerius 2 years ago.
Executable file corruption log

Download all attachments as: .zip

Change History (4)

Changed 2 years ago by valerius

Executable file corruption log

comment:1 Changed 22 months ago by valerius

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

comment:2 Changed 22 months ago by valerius

Now it's fixed, so closing it.

comment:3 Changed 22 months ago by valerius

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.