Comment 8 for bug 59293

Duncan wrote:
> But since fat doesn't support it I suggest we don't try and make it make complicated than necessary

With hindsight, I'll have to reluctantly agree. Kludging even more proprietary enhancements onto FAT has the potential to create more problems than it solves, especially because Windows would have ignored the "magic fsck record" anyway.

> Write a simple hidden text file with configuration info onto the fat partition. I might be called .mount-conf .

I am concerned it would be unneccessarily difficult to access .mount-conf on an up to this point *unmounted* file system, especially if said file system might be in an inconsistent state, in which case we'd have to run fsck first, which has to access .mount-conf -- a chicken-and-egg problem.

> The boot sequence could probably be configured to run dosfsck at certain intervals of uptime.

After the boot process has completed, the FAT partitions are probably mounted. I don't think dosfsck supports repairing live FAT volumes.

> If I remeber rightly, the final two numbers, both zero in this example, tell the system to continue booting if it can't find this partition (the first zero)

According to fstab(5), it's a signal for dump whether this partition needs or needs not to be dumped.

> and to not check it's integrity (the second zero)

This workaround works as long as users always cleanly unmount their filesystems. Which, in case of e.g. a kernel panic, is not given. Not checking at all and risking creeping integrity damage seems worse to me than checking too often. So, should we advise users to take this risk?