print out the values of the bytes that do not match.
Add comment explaining that there is no documented rationale for the
check.
fsck_msdos checks that several bytes are equal in the primary and
backup bootblock. There is no documented rationale. The kernel does
not enforce this when mounting a filesystem. I have a FAT32
filesystem on my disk (mounted as /share) which fails this check, but
is accepted by both Windows XP and NetBSD. My volume differs in bytes
71-81. The primary contains "SHARE " and the backup NUL bytes.
Further, fsck_msdos does not have code to repair the mismatch. As a
result such filesystems can be used not checked.
Make sure that each va_start has one and only one matching va_end,
especially in error cases.
If the va_list is used multiple times, do multiple va_starts/va_ends.
If a function gets va_list as argument, don't let it use va_end (since
it's the callers responsibility).
Improved by comments from enami and christos -- thanks!
Heimdal/krb4/KAME changes already fed back, rest to follow.
Inspired by, but not not based on, OpenBSD.
that it's possible to compile this with -Wstrict-prototypes -Wmissing-prototypes
Breakage reported by Jeff Rizzo <riz@boogers.sf.ca.us> on current-users.
it just as "odd byte sequence". Handle the dirty flag similar way
it's treated on e.g. FFS - e.g. clear it separately from rest of FAT.
Changing of FAT is now postponed until after all checks are done,
check.c:checkfilesys() was cleaned considerably and several messages
has been adjusted to be more accurate.
If file system was modified and no error has occured, just return 0
instead of 4 - there is no need for forcing a reboot in this case.
This addresses bin/5638 by Christos Zoulas.
Print correct pathname in error messages
Fix unterminating loop when trying to correct a bad fat
Require fat media byte to be the same as the one in the bpb
Fix unterminating loop when looking for free directory slot in LOST.DIR
(bad disk image provided by Christoph Badura)
christos