David D. Hagood wrote:
> Jos Hulzink wrote:
>> How should the FAT driver know that the first FAT is bad if it doesn't
>> scan the FAT ? You don't want the second FAT to be used, you want the
>> mount to fail, and fsck.xxx to fix the mess. Who tells you that the
>> copy of the FAT is the correct one, and not the first ?
> Seems to me you would want a mount-time option to the FAT fs code to say
> "use FAT#<n>", defaulting to the first if no parm given. If that copy of
> the FAT has any problems, fail the mount.
> Then you'd want the fsck.fat to have a similar option, saying "use
> FAT#<n> for the check" - that way if the FATs are out of sync, you could
> do a dry run check on each FAT, and go with the one that seemed to be
> better. Perhaps even having the tool allow you to pick and choose if
> needed (although this would probably be better as a seperate tool, that
> allowed you to view a file given a selected FAT and copy it to a clean
> file system.)
If I apply the "Think big" patch for a second, I say, check individually
for each entry with fsck.fat and build a fat of the entries that are
still ok. This could be a special --rebuild option or whatever.
-- Thunder from the hill. Citizen of our universe.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/