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

[Ady]

> > 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.