a live file system.
While here modify snap_open() to accept a character device as its
first arg and remove now unneeded get_snap_device().
Reviewed by: Manuel Bouyer <bouyer@netbsd.org>
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.
wiz