Re: End of FAT directories

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >  For overwriting the
> > zeroed entry, why we have to check all entries until see next zeroed
> > (yeah, now, we allowed the crappy data after zeroed)?
> My point was not about checking all entries until the next zeroed entry,
> which is overcomplicating stuff. I meant that if we hit the end (i.e.
> the first zeroed entry) when searching for free slots, in that case we
> just clear the one entry directly following the inserted entries. This
> makes sure that no files magically appear. I *do* understand that

This sounds like a good idea, and costs nothing. I hope we can
convince Ogawa...

> In the end, there are two valid interpretations on the problem at hand:
>  - DOS/Windows is buggy in exposing the crap when filling the "hole",
> which is proven by chkdsk not complaining about the garbage in the
> directory, and we should not follow the bug in DOS/Windows
>  - chkdsk is buggy in not complaining about trailing garbage in
> directories, which are proven to be invalid by DOS/Windows messing up on
> them, and we shouldn't complicate our FAT implementation by trying to
> work around a bug in chkdsk.

I believe 2) is the case; but we should still work around that chkdsk
bug.

> I think the *most* important fact is to have at least dosfsck and linux
> consistent about directories with trailing garbage. So I won't even try
> to submit a patch to the Linux kernel that stops reading at the first
> unused directory entry if dosfsck will not accept to stop reading at the
> first unused directory entry.

They should *not* be consistent.

Kernel should stop at zero invalid entry.

fsck should consider any garbage past zero entry as an error, and zero
it out. (Complaining about duplicate blocks is unhelpful but better
than nothing.  It should really zero the garbage out.)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html