[syslinux] [PATCH 1/5] fat: fix minfatsize for large FAT32
Pete Batard
pete at akeo.ie
Thu Feb 25 04:41:54 PST 2016
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
More information about the Syslinux
mailing list