User:Heis Spiter

From ReactOS Wiki
Jump to: navigation, search
Pierre Schweitzer
Rank
IRC nickname HeisSpiter
Location France
E-Mail pierreКльомба.pngreactos.org
Homepage [1]


Profil

Scope of interest in ReactOS Development: FileSystems, kernel, RosBE

SysAdmin

As one of the ReactOS system administrators, feel free to contact me in case you think that something is going wrong with one of the servers or services running on them.

No need to contact me with purely web related stuff, I'm not one of the ReactOS web teamlers.

Details about the IPv6 migration of the infrastructure: IPv6.

Scratchpad

Various notes about debugging FastFAT (FAT32), clean shutdown bit and autochk.

When formating in FAT32, the clean shutdown bit (1 << 31) is never removed on partition mount. This is due to the fact that the four upper bits are "reserved" with FAT32 and thus never written in our FSD (left to 0xF). Removing the clean shutdown bit would lead to write 0x7 instead. This never happens. This can easily be fixed though. In case of a fix there, it's mandatory to also fix reading so that the FSD can know when it's mounting an unclean volume (otherwise, it's hidden - only the lower 28 bits are returned). This can be easily hacked in fat.c in FAT32GetNextCluster and in FAT32WriteCluster.

Regarding vfatlib, I'm not really sure it's current structure is correct. It starts fixing the FS before writing "performing changes". It also never sets the clean shutdown bit, so, the FSD will be seen dirty even after a full repair (is vfatlib really supposed to do so?). Note that making vfatlib setting the clean shutdown bit will require a fix similar to what I proposed for FastFAT (and FAT32); its read/write routine also honor the four upper reserved bits.

But, there's a bigger issue with autochk. Currently, it cannot repair properly the system partition. To do so, it requires: locking the volume, repairing, dismounting, unlocking. To be able to lock the volume, only one handle must be left open on the volume: the volume itself. autochk being started in umode "normally", it has a working directory, set to System32, which leads to have at least one handle open to this directory. This prevents FS locking, dismounting, and so on. I have so far no idea about how to fix this properly.

Fixing these three issues should bring the following features to ROS: unsetting the clean shutdown bit on a FAT32 volume will lead this volume to be checked on the next reboot. Even if it's the system partition. The clean shutdown bit being cleared on volume mount, it would make the volume being checked for errors at reboot in case of hard reboot/BSOD, whatever.

Homepages: