[syslinux] [PATCH] git tree: libfat, chain, mtools/syslinux, menu.txt

[Gene Cumm]

On Wed, Aug 25, 2010 at 18:50, Gene Cumm <gene.cumm at gmail.com> wrote:
> On Wed, Aug 25, 2010 at 18:17, Gene Cumm <gene.cumm at gmail.com> wrote:
>> Another approach to take is to open it with libfat_open() (original)
>> back before ldlinux.sys is dropped in, close it if it opens
>> successfully and announce the file system is corrupt, forcing the user
>> to fix it first.
>
> Come to think of it, I can name two reasons we should use
> libfat_open() (whichever version is your preference) before we even
> think about touching the disk/image.
>
> 1) If the file system is genuinely corrupt, copying in ldlinux.sys
> will only make matters worse.
>
> 2) If we're successful in dropping in an ldlinux.sys, failing later
> would only lead to end user confusion and frustration for why their
> partition is not bootable.  grep'ing the code, libfat_open is in
> mtools, dos, and win syslinux.c after ldlinux.sys is written.

Based on discussions here and IRC, I have a proposal.  For the
libfat-linked installers, put in a quick open/close just before the
first write to make sure libfat_open() is happy with the file system
at the relatively minor cost of the open/close.  Option "-f" would
activate the code I made, preserving the old behavior without it
(opt.force passed as new parameter to libfat_open(), ie tryForce,
doForce, force).  Additionally, remove "MTOOLS_SKIP_CHECK=1"  (and
possibly "MTOOLS_FAT_COMPATIBILITY=1") from the mtools config unless
-f is specified.  Also document it in usage(), doc/syslinux.txt, and
probably NEWS.

Another option is to introduce a new option that gently encourages
some broken behavior but does not force it as hard as possible.

Thoughts/comments?

-- 
-Gene