Custom Query (69 matches)

WinNT supports big 64KB (128 sectors) clusters, which fat32.ifs did not supported. Fat32format seems to support 128 sectors per cluster (so, the new FORMAT should support it too). So, we will try to extend other parts to understand these.

It appears that fat32.ifs requires the disk driver with strat2 support, and it uses it in the cache code to queue the i/o requests. But it assumes that strat2 is supported, and we'll get a trap in FS_MOUNT in case it isn't. The drivers supporting strat1 only, do exist, for example, it is hd4disk.add driver for PAE ramdisk. It uses it because strat1 is simpler, and faster. Actually, hpfs.ifs works almost 10 times faster with strat1 switch given to hd4disk.add.

So, we need to handle gracefully the case of the disk driver, supporting strat1 only. -- We can just refuse to mount if the disk driver is strat1 only. This should be easy, but the full support for using strat1 only is harder to implement (need to change the cache logic)

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.