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 <hpous...@reactos.org>
> ---
> 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?
Kevin
