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

Hi Gene,

On 2016.02.26 11:49, Gene Cumm wrote:
> I think there may be another answer to this:
>
> 1) a tool to fix the broken FSs by "wasting" the high clusters of
the
> file system, a non-destructive correction.  As it stands they're
> effectively wasted already and might risk a user thinking the file
> system isn't full when in fact the FAT itself is.
I'm not exactly sure how that would work (how would you mark those 
clusters as wasted when my understanding is that the FAT's can't provide
any knowledge about them in the first place?) and unless it is 
automatically integrated and ran during the Syslinux installation, it 
sounds quite inconvenient for users.
> 2) The recommendation to use the Syslinux installer's "-f"
flag until
> the individual file system is corrected with the above tool, assuming
> "-f" circumvents this check.  I've been tossing the idea
around that a
> single "-f" might not be the best answer and a longer option
> specifying a list of checks to skip might be more balanced, ie "-F
> minfatsize,othercheck".
>
> 3) Ensure that the Syslinux installers state which check failed to
> assist users in correcting their file system, regardless of if
"-f" is
> specified.  If "-f" is not specified, installation should fail
> completely (hopefully with 0 alterations).  If "-f" is specified
but
> not necessary (indicating a user/tool that isn't being cautious),
> consider throwing a warning while still allowing the install and
> returning a success to the caller of the installer.
Joining on what you advocate above, I think I'd indeed prefer an 
installer that fails when -f isn't used, with an explicit message 
stating why (maybe with a computation of the number of sectors that 
cannot be addressed, so that users have a good idea of the wastage) 
along with an indication that they can use '-f' use to bypass that 
check, should they want to.

Since I brought this whole thing up, and provided this is the course of 
action everybody agrees on, I *may* try to work on a patch that does 
this... bearing in mind that, as you know, the last time I said I'd work 
out some patches for Syslinux (this series), it took about 3 months 
before I posted anything. ;)

Regards,

/Pete

On Fri, Feb 26, 2016 at 8:10 AM, Pete Batard via Syslinux
<syslinux at zytor.com> wrote:
> Hi Gene,
>
> On 2016.02.26 11:49, Gene Cumm wrote:
>>
>> I think there may be another answer to this:
>>
>> 1) a tool to fix the broken FSs by "wasting" the high
clusters of the
>> file system, a non-destructive correction.  As it stands they're
>> effectively wasted already and might risk a user thinking the file
>> system isn't full when in fact the FAT itself is.
>
>
> I'm not exactly sure how that would work (how would you mark those
clusters
> as wasted when my understanding is that the FAT's can't provide any
> knowledge about them in the first place?) and unless it is automatically
> integrated and ran during the Syslinux installation, it sounds quite
> inconvenient for users.
Total size and last-known free space should be adjusted accordingly.
I don't think there's anything more but a fsck/chkdsk or similar tool
should also be able to fix this error.  Ending the file system before
the end of the partition may seem unusual but helps in this instance.
>> 2) The recommendation to use the Syslinux installer's
"-f" flag until
>> the individual file system is corrected with the above tool, assuming
>> "-f" circumvents this check.  I've been tossing the idea
around that a
>> single "-f" might not be the best answer and a longer option
>> specifying a list of checks to skip might be more balanced, ie "-F
>> minfatsize,othercheck".
>>
>> 3) Ensure that the Syslinux installers state which check failed to
>> assist users in correcting their file system, regardless of if
"-f" is
>> specified.  If "-f" is not specified, installation should
fail
>> completely (hopefully with 0 alterations).  If "-f" is
specified but
>> not necessary (indicating a user/tool that isn't being cautious),
>> consider throwing a warning while still allowing the install and
>> returning a success to the caller of the installer.
>
>
> Joining on what you advocate above, I think I'd indeed prefer an
installer
> that fails when -f isn't used, with an explicit message stating why
(maybe
> with a computation of the number of sectors that cannot be addressed, so
> that users have a good idea of the wastage) along with an indication that
> they can use '-f' use to bypass that check, should they want to.
>
> Since I brought this whole thing up, and provided this is the course of
> action everybody agrees on, I *may* try to work on a patch that does
this...
> bearing in mind that, as you know, the last time I said I'd work out
some
> patches for Syslinux (this series), it took about 3 months before I posted
> anything. ;)
Thinking now. perhaps automating a check and/or fix into a tool
running a Syslinux installer might be a good idea.

-- 
-Gene

On 02/26/16 09:54, Gene Cumm via Syslinux wrote:
>>
>> I'm not exactly sure how that would work (how would you mark those
clusters
>> as wasted when my understanding is that the FAT's can't provide
any
>> knowledge about them in the first place?) and unless it is
automatically
>> integrated and ran during the Syslinux installation, it sounds quite
>> inconvenient for users.
> 
> Total size and last-known free space should be adjusted accordingly.
> I don't think there's anything more but a fsck/chkdsk or similar
tool
> should also be able to fix this error.  Ending the file system before
> the end of the partition may seem unusual but helps in this instance.
> 
And that is, indeed, what this formatter should do if it wishes to
continue using this specific algorithm for some reason.  This is, in
fact, required anyway for some specific reasons.

That being said, if Windows accepts such a filesystem then Syslinux
really should, too; perhaps with a warning.  libfat is sometimes overly
paranoid, on purpose, in order to avoid problems.

It is also worth noting that someone ported mkdosfs to Windows; perhaps
the best thing would be if this could be folded into the stock
dosfstools upstream (if it hasn't been already):

	http://www1.mager.org/mkdosfs/

	---

TL;DR: Ridgecrop's tool has a bug that needs to be fixed.  They can
either extend the FAT size to cover the entire volume, or they can
adjust the filesystem size to account for the limited size of the FAT.
Both are legitimate; which one results in the higher capacity is the
preferred one (which will usually be making the FAT larger.)

However, if Windows accepts this, and *especially* if chkdsk doesn't
take any action, we really ought to change Syslinux to match.