Re: FAT-filesystem EOF marker problem

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <Pine.LNX.4.33L2.0209222319590.20873-100000@dragon.pdx.osdl.net>
By author:    "Randy.Dunlap" <rddunlap@osdl.org>
In newsgroup: linux.dev.fs.devel
> |
> | 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.
> 
> And the value that I see there is 0xfff.
> 

Fat entry 0 contains the media descriptor byte, and fat entry 1 *used*
to contain the EOC mark, but has been retconned as the volume dirty
bit (Microsoft OSs don't recognize a volume dirty flag for FAT12,
however; this is presumably because of the MS assumption that FAT12 ==
floppy.):

For FAT16: ClnShutBitMask = 0x8000; HrdErrBitMask = 0x4000;
For FAT32: ClnShutBitMask = 0x08000000; HrdErrBitMask = 0x04000000;

Bit ClnShutBitMask   If bit is 1, volume is  clean . If bit is 0,
volume is  dirty . This indicates that the file system driver did not
Dismount the volume properly the last time it had the volume
mounted. It would be a good idea to run a Chkdsk/Scandisk disk repair
utility on it, because it may be damaged.

Bit HrdErrBitMask   If this bit is 1, no disk read/write errors were
encountered. If this bit is 0, the file system driver encountered a
disk I/O error on the Volume the last time it was mounted, which is an
indicator that some sectors may have gone bad on the volume. It would
be a good idea to run a Chkdsk/Scandisk disk repair utility that does
surface analysis on it to look for new bad sectors.

Either way, I vote we should always use all ones of the EOC mark.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<amsp@zytor.com>