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

Gene Cumm gene.cumm at gmail.com
Wed Aug 25 15:17:05 PDT 2010


On Wed, Aug 25, 2010 at 18:09, H. Peter Anvin <hpa at zytor.com> wrote:
> 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...

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.

fsck.vfat (not sure on its original name; I'm accustomed to calling
fsck and mkfs by the standardized name) currently can't deal with
this.

The fixfat utility I created checks/tweaks the one value.  If you call
it without -f it checks and the return code says if it's needed.  With
-f, it'll return an error if it really is a sane value.  This forces
you to run it twice if you're paying attention to the returns to
attempt to make a user use it correctly if it's in a script, just to
be a little paranoid.

-- 
-Gene




More information about the Syslinux mailing list