Update FAT32 FSInfo after root dir allocation - #108
Conversation
fsck.vfat doesn't error when in `-n` mode, so we pass `-y` to have it fix anything it finds, and if it fixes something it will exit with status code 1.
|
Didn't mean to close this, whoops. |
rafalh
left a comment
rafalh
left a comment
There was a problem hiding this comment.
Nice idea to initialize FSInfo sector with the actual data.
AFAIK the previous behavior was compliant with the spec - fields were initialized to -1/0xFFFFFFFF as indicated by the spec to indicate unknown values, but I get that not passing fsck is not nice + there is no reason to not fill those fields.
I left some suggestion to simplify the code.
Overwrite the FSInfo sector once the root directory cluster is allocated
so free-cluster counts match the FAT and fresh images pass fsck cleanly.
Prior to this change, FAT32 disks created by this library would fail `fsck.vfat` like so:
fsck.fat 4.2 (2021-01-31)
Free cluster summary uninitialized (should be 66535)
Auto-setting.
*** Filesystem was changed ***
Writing changes.
/tmp/test-fat32.img: 0 files, 1/66536 clusters
Now, they pass:
fsck.fat 4.2 (2021-01-31)
/tmp/test-fat32.img: 0 files, 1/66536 clusters
3499b7f to
0fb7dd1
Compare
rafalh
left a comment
rafalh
left a comment
There was a problem hiding this comment.
Please add FAT16 test.
I can see that build with old Rust fails, but don't worry about it. It can be fixed in a separate PR by bumping minimal Rust version.
|
Sorry for the delay. I didn't notice you added FAT 16, because you didn't request a re-review and I didn't get a notification. Thanks for the contribution! |
2 participants
Overwrite the FSInfo sector once the root directory cluster is allocated
so free-cluster counts match the FAT and fresh images pass fsck cleanly.
Prior to this change, FAT32 disks created by this library would fail
fsck.vfatlike so:Now, they pass: