On at 2018-02-06 16:41 +01:00, Daniel Kiper wrote:
>>> I am happy that you fix that issue but
>>> https://en.wikipedia.org/wiki/Design_of_the_FAT_file_system#BPB331_OFS_15h
>>> shows that life is more complicated.
>>>
>>> Could you take that into account?
>>
>> MS-DOS 3.20 and 3.30 BPBs aren't
On Wed, Jan 31, 2018 at 12:39:05PM +0100, C. Masloch wrote:
> On at 2018-01-29 18:09 +01:00, Daniel Kiper wrote:
> > On Sun, Jan 21, 2018 at 04:02:10PM +0100, C. Masloch wrote:
> >> The definition of bpb's num_total_sectors_16 and num_total_sectors_32
> >> is that either the 16-bit field is
On at 2018-01-29 18:09 +01:00, Daniel Kiper wrote:
> On Sun, Jan 21, 2018 at 04:02:10PM +0100, C. Masloch wrote:
>> The definition of bpb's num_total_sectors_16 and num_total_sectors_32
>> is that either the 16-bit field is non-zero and is used (in which case
>> eg mkfs.fat sets the 32-bit field
On Sun, Jan 21, 2018 at 04:02:10PM +0100, C. Masloch wrote:
> The definition of bpb's num_total_sectors_16 and num_total_sectors_32
> is that either the 16-bit field is non-zero and is used (in which case
> eg mkfs.fat sets the 32-bit field to zero), or it is zero and the
> 32-bit field is used.
The definition of bpb's num_total_sectors_16 and num_total_sectors_32
is that either the 16-bit field is non-zero and is used (in which case
eg mkfs.fat sets the 32-bit field to zero), or it is zero and the
32-bit field is used. Therefore, a BPB is invalid only if *both*
fields are zero; having
