Re: FAT-filesystem EOF marker problem

["Randy.Dunlap" <rddunlap@osdl.org>]

On Mon, 23 Sep 2002, OGAWA Hirofumi wrote:

| "Randy.Dunlap" <randy.dunlap@verizon.net> writes:
|
| > 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].
|
| I vote to (a). It should be very easy for 2.5.x. And I think that you
| explained why we should use standard EOF mark.
|
| So, what do you think of trying (a), until the reason we need values
| other than standard EOF(fff/ffff/fffffff) is found?

Sure, that sounds fine to me.  I expect it to be fairly safe.
And if we did (c), we should use 0xfff instead of 0xff8 as the
default now that I've had more time to think about it.

-- 
~Randy