Syslinux - Feb 2016 - [PATCH 1/5] fat: fix minfatsize for large FAT32

When trying to installing Syslinux on a FAT32 drive formatted using 
Ridgecrop's Large FAT32 formatting tool [1], the installer will bail due 
to the minfatsize check, as there is an extra sector being used. This 
fix addresses that.

[1] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm
-------------- next part --------------

> When trying to installing Syslinux on a FAT32 drive formatted using 
> Ridgecrop's Large FAT32 formatting tool [1], the installer will bail
due
> to the minfatsize check, as there is an extra sector being used. This 
> fix addresses that.
> 
> [1] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm
> 
The expression:
"...as there is an extra sector being used."

is not clear (to me).

There is an "extra" sector, in comparison to... what exactly?

For instance... Are there other formatting tools (in whichever OS) that 
are capable of similar "large" FAT32 volumes (i.e. volume size
>32GB,
"big" cluster size) that do not use this "extra" sector? Or
is it
"extra" when comparing the resulting "large" volume to
smaller FAT32
ones? Or is it "extra" in contrast to something else?

Is this "extra" sector compatible with any OS / diverse scenarios? (I 
know about the limitations of certain formatting tools, but that's not 
the matter in question here.)

I guess that the most important matter would be to be sure that there 
are no regressions introduced (i.e. that other FAT12/16/32 volumes 
would work in Syslinux just as before this patch). Since I am not a 
developer, I am not getting into such issues now.

I'm not even sure I am expressing my question clearly / correctly, but 
I am hoping it can be understood anyway; if it is not so, please let me 
know and I'll try again.

Perhaps the answer is clear to others (maybe from the patch itself). I 
would still appreciate replies to this question.

TIA,
Ady.

Hi Ady,

On 2016.02.25 02:08, Ady via Syslinux wrote:
> There is an "extra" sector, in comparison to... what exactly?
Sorry if I wasn't clear. I think I implied that the Large FAT32 fat size 
had an extra sector compared to minfatsize, when of course I meant the 
opposite (the Large FAT32 has one less sector than the minfatsize 
computed by the unpatched code, hence the check fails). The additional 
sector I was talking about is from the (unpatched) minfatsize variable 
computed in libfat_open() when it is compared to the fatsize variable.

If you use a Large FAT32 formatted drive, you will see that fatsize is 
always less than (unpatched) minfatsize by a difference of 1, and my 
understanding is that these values are expressed in number of FAT 
sectors. So I guess it'd probably be more accurate to say that what I 
found is that Large FAT32 formatted drives have one less sectors of FAT 
than SysLinux anticipates right now.

To make this a bit more concrete, here is the debug output of a 100GB 
drive being formatted to Large FAT32 and then processed with the 
_PATCHED_ version of libfat_open(), with display of the relevant variables:

-----------------------------------------------------------------------
Formatting (Large FAT32)...
Opened drive \\?\Volume{00466cbf-0000-0000-0000-100000000000} for write 
access
Size : 93.2 GB 195369519 sectors
Cluster size 32768 bytes, 512 Bytes Per Sector
Volume ID is 1311:f60
32 Reserved Sectors, 23843 Sectors per FAT, 2 FATs
3051903 Total clusters
3051902 Free Clusters
Clearing out 47782 sectors for reserved sectors, FATs and root cluster...
Initializing reserved sectors and FATs...
FAT #0 sector at address: 32
FAT #1 sector at address: 23875
Writing partition boot record...
Using Standard FAT32 partition boot record
Confirmed new volume has a primary FAT32 boot sector
Setting primary FAT32 boot sector for boot...
Confirmed new volume has a secondary FAT32 boot sector
Setting secondary FAT32 boot sector for boot...
Setting Label (This may take while)...
Format completed.
Writing master boot record...
(...)
Installing Syslinux 6.03...
Opened drive \\?\Volume{00466cbf-0000-0000-0000-100000000000} for write 
access
nclusters  = 3051903
fat_type   = FAT28, LIBFAT_SECTOR_SHIFT = 9
minfatsize = 23843 (patched, after shift)
fatsize    = 23843
Successfully wrote Syslinux boot record
-----------------------------------------------------------------------

If minfatsize wasn't patched (original Syslinux code) it would be 23844 
due and the (minfatsize <= fatsize) check would fail.
> For instance... Are there other formatting tools (in whichever OS) that
> are capable of similar "large" FAT32 volumes (i.e. volume size
>32GB,
> "big" cluster size) that do not use this "extra"
sector?
I don't think it matters. Ridgecrop's Large FAT32 formatting algorithm 
is fairly popular, so I don't think we can go around telling people 
"Sorry, you'll have to use something else because we don't want to 
change what is essentially a sanity check in Syslinux..."
> Is this "extra" sector compatible with any OS / diverse
scenarios?
Well, it certainly is compatible with Windows, DOS/FreeDOS and Linux 
installers, as this is what I use in Rufus for large drives, and so far 
I have not had a single report from anybody having trouble 
reading/writing to a Large FAT32 drive. As a side note, Rufus gets 
downloaded close to 2 million times a month, and I expect a significant 
percentage of these users to both have a drive large enough (>32GB) and 
a target that requires the use of FAT32 (Linux ISOs, DOS). Therefore, if 
the use of Ridegcrop's Large FAT32 was the source of any issues, I'd 
have had plenty of reports by now...
> I guess that the most important matter would be to be sure that there
> are no regressions introduced (i.e. that other FAT12/16/32 volumes
> would work in Syslinux just as before this patch). Since I am not a
> developer, I am not getting into such issues now.
My understanding is that the minfatsize check is just a sanity check 
(i.e. we could drop it and it wouldn't hurt Syslinux that much - users 
might just get an error further down the line), and what we are doing by 
increasing minfatsize is simply making this check slightly more 
permissive. So there is literally no risk for a regression being 
introduced, as whatever passed that test before will still pass the test.

The worst that could happen is that we may allow stuff that wouldn't 
have passed before. But, as the processing of Large FAT32 volumes 
demonstrates, that may not be a bad idea, as this check seems to be 
based on an understanding of FAT limitations that doesn't seem grounded 
in physical reality: it is most certainly possible to create valid FAT 
volumes, as far both Windows and Linux are concerned, for which the 
check doesn't hold. So I do believe that we should relax the check 
slightly, as the patch proposes.

Regards,

/Pete