Thank you David for the suggestion.  You were right, a hex dump of the
filesystem revealed the problem.  I've submitted a patch in kern/32003
which fixes the problem.  The problem is that the msdosfs code does not
insure that the bytes in the directory entry which are used for pointing at
high cluster numbers on FAT32 filesystems are not zeroed out on non-FAT32
filesystems.
	Any chance someone could commit this patch to the various branches,
or, failing that, argue why it should not be committed?
-thanks
-Brian
On Nov 2,  9:15pm, David Laight wrote:
} Subject: Re: msdosfs directory bug -- any helpers out there?
} On Wed, Nov 02, 2005 at 08:34:44AM -0800, Brian Buhrow wrote:
} > 	Hello.  Following up on my own post, I've been looking into the
} > msdosfs code, and I find I have a question which I think should be easy to
} > answer for someone who knows.
} > 	When the msdosfs code creates a new directory entry, I can't tell if
} > it always appends to the directory, never reclaiming previously deleted
} > entries, or if it tries to re-use deleted slots.  Does anyone know who
} > would be willing to say?
} 
} I suspect you need to inspect a hexdump of the filesystem image by hand!
} Given the extreme simplicity of the FAT filesystem this isn't that hard.
} What I would look for is the contents of ddirectory blocks that contain
} deleted files.
} 
} 	David
} 
} -- 
} David Laight: david@l8s.co.uk
>-- End of excerpt from David Laight