FAT-filesystem EOF marker problem

["Randy.Dunlap" <randy.dunlap@verizon.net>]

Hi,

On 2002-Sept-15 a Linux-USB user reported a problem when using
a file written by Linux to a CompactFlash (CF) card in an MP3
player.  Linux and Windows can still read the CF card correctly,
but the MP3 player cannot.  I have successfully reproduced this
problem.

Initial problem report and thread begin at:
http://marc.theaimsgroup.com/?l=linux-usb-users&m=103210507227709&w=2

I found several Boot Record/BIOS Parameter Block differences,
one FAT cluster link difference (EOF marker), and several
directory entry differences.  I believe that I have proved
that the problem lies in the FAT EOF marker difference:

Windows (ME version at least) writes 0xfff for a FAT12 EOF marker.
mtools writes 0xfff for a FAT12 EOF marker.
Linux (v)fat filesystem writes 0xff8 for a FAT12 EOF marker.
(Yes, I know that 0xff8 is a valid FAT12 EOF marker.)

This causes some cheap/crappy MP3 player(s) firmware to get lost...
yeah, it's a problem with the MP3 player(s).
And Linux users can get around the problem by using mtools
instead of a Linux filesystem, but sometimes using a filesystem
is just preferred.

Anyone have any suggestions for other workarounds or patches?

I would prefer to see something like (a) Linux uses 0xfff for
FAT(12) EOF [and sign-extended for FAT16 and FAT32], or
(b) Linux uses a mount option to indicate the EOF marker value,
or (c) Linux dynamically checks what EOF marker value is in
the FAT already, and continues to use that value [and continues
to use 0xff8 as its default value].

Thanks,
~Randy