[syslinux] [PATCH 1/5] fat: fix minfatsize for large FAT32

Ady
2016-02-26T15:32:29Z

> > instead of _always_ adding "+1" (which would be
> > incorrect and inefficient from the point of view of the resulting
> > allocatable size).
>
> I carefully considered this, and I dispute the fact that this is incorrect.
>

 (snip)

> Still, I won't prevent you (or anybody else interested) to provide a
> proper formula if you want. ;)
>
> Regards,
>
> /Pete
>

You know I am not a developer, so I cannot comment about the
difficulties of achieving a more accurate calculation using computer
code.

As I mentioned in my previous email, I am not saying that some / any
code is "wrong"; I am only presenting the math as accurate as I can.

Regarding the "+1", when talking about the math (not the computer code
to achieve a result as accurate as it can be), I already expressed the
difference between using math operators such as "integer",
"quotient",
"modulo", "remainder"... as opposed to just using
"+1". Clearly, if the
result is already an integer (in the math, not in whichever computer
code), then adding "+1" to that value is incorrect. In fact, the same
goes to a fraction: adding "+1" to such value will result also in a
non-integer value. Once again (sorry), I am talking math, not computer
code.

As per the "big" numbers and accuracy, again, I cannot comment on
computer code. I do want to remind you that, besides the "generic"
determination of an "adequate" minfatsize in Syslinux's code, we
should
at least test the values that are around or close to the limits between
FAT12/16/32.

For simplicity, I'll give basic examples (which I have not truly
analyzed; developers could / should test relevant code).

Example A:
Volume_Total_Sectors: 66'463
FAT type: FAT32
Bytes_per_sector: 512
Sectors_per_Cluster: 1
Sectors_per_FAT: 511 ---> this value should _not_ be accepted as valid
minfatsize; 512 should be OK.

Example B:
Volume_Total_Sectors: 4'187'104
FAT type: FAT32
Bytes_per_sector: 512
Sectors_per_Cluster: 64
Sectors_per_FAT: 511 ---> this value should _not_ be accepted as valid
minfatsize; 512 should be OK.

I have not actually searched potential conflicting values; the above 2
examples are just "around" the lower size limit of FAT32.

Let me put the example(s) in other words. Whichever calculation of
minfatsize you use, values such as a Volume_Total_Sectors around:

 65'518 ... 66'463

should be tested (among others; I could provide more ranges for
testing). Such values are close to the lower limit of FAT32, and,
depending on additional fields, they can be problematic (and at least
some of them should be rejected).

I am not saying that these are typical values for FAT32 volumes that
users would see / use in real life (but they might); this range is just
a source for testing either the acceptance or rejection of a FAT32
volume (in Syslinux's code).

BTW, please note that these values are not really "big" (although, for
computer code there might still be an "accuracy" problem; I
wouldn't
know).

I have not provided more details (nor performed actual analysis)
regarding these values (or some others), because at this time I fear I
could be just wasting my time in math (since I am not a developer that
can actually translate it into useful code). If there would be any
practical development in the code, I am willing to invest my time too
(but I would like to know it, before I decide to use my time in such
endeavour :).

At any rate, I certainly appreciate the people that already dedicated
the time,
knowledge, resources, skills... in this email thread and in this set of
patches.

Regards,
Ady.