Am 15.05.2017 um 22:31 hat Hervé Poussineau geschrieben:
Specification: "FAT: General overview of on-disk format" v1.03, page 11
Signed-off-by: Hervé Poussineau <address@hidden>
---
block/vvfat.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/block/vvfat.c b/block/vvfat.c
index f60d2a3889..348cffe1c4 100644
--- a/block/vvfat.c
+++ b/block/vvfat.c
@@ -218,10 +218,12 @@ typedef struct bootsector_t {
union {
struct {
uint8_t drive_number;
- uint8_t current_head;
+ uint8_t reserved1;
uint8_t signature;
uint32_t id;
uint8_t volume_label[11];
+ uint8_t fat_type[8];
+ uint8_t ignored[0x1c0];
} QEMU_PACKED fat16;
struct {
uint32_t sectors_per_fat;
@@ -233,8 +235,6 @@ typedef struct bootsector_t {
uint16_t ignored;
} QEMU_PACKED fat32;
} u;
- uint8_t fat_type[8];
- uint8_t ignored[0x1c0];
uint8_t magic[2];
} QEMU_PACKED bootsector_t;
At least, this makes it clear that .fat16 and .fat32 aren't the same
length. But maybe it would be cleaner to have a third union member
uint8_t bytes[0x1da] (if I calculated correctly) instead of relying on
the .fat16 branch to extend the space for .fat32?