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

[H. Peter Anvin]

On 08/25/2010 03:01 PM, Gene Cumm wrote:
> 
> Sure.  I wouldn't think it would end up corrupting a live file system
> as it's supposed to only have read access.
> 

Sort of... we use the sector maps produced by libfat to write "blindly"
to the filesystem.

> It doesn't "defang" all of the sanity check.  it just sees that,
> technically, the file system is corrupt.  Specifically, the FAT itself
> is too short for the the declared number of sectors in bsSectors or
> bsHugeSectors.  It attempts to compute a possibly sane value and
> redoes the sanity check with the new value.  If the new value passes
> the sanity checks, it's usable.  This serves to essentially ignore the
> end of the file system in favor of what can really be allocated in the
> FAT.
> 
> For a time, Dell was making images that were corrupt in this manner.
> Both Linux and mtools seem to ignore this corruption.
> 
> The other idea (which is how I found out the exact failure) is to
> either barf to unique locations or set errno then go to barf such that
> an enduser is informed how the file system failed the checks.
> 
> I'm starting to see what you might be thinking about: Syslinux is
> pointed at a random jumble of bits that happen to resemble a FAT file
> system and only bsSectors or bsHugeSectors is off from passing all
> checks for probably being a valid file system.

Something like that, yes; or it's a filesystem which genuinely is
corrupt, and we don't want to do more harm.

I've been very conservative about this, but ultimately I guess if the
operating systems allow it to be read/written then maybe that's good
enough...

	-hpa