Re: FAT-filesystem EOF marker problem

[Andries Brouwer <aebr@win.tue.nl>]

On Sat, Sep 21, 2002 at 10:30:19PM -0700, Randy.Dunlap wrote:

> 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

There seem to be many more people with this problem.
One web page describing it is
http://home.earthlink.net/~ebrombaugh/fattools.html

> 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.

> 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].

My docs say: FAT entry 0 contains the media descriptor byte.
FAT entry 1 contains the EOF marker, except that the high order two
bits can be used for other purposes.

So, I would like to reject (b) - if a device does not work, very few
people will get the idea that the end-of-file marker used by the
FAT filesystem is to blame. And (a) is reasonable, that is what
Microsoft does. And (c) might be replaced by (c'): read the desired
EOF marker from FAT entry 1. If that yields an invalid value, use
what Microsoft does: 0xfff.

Andries