fsck_msdosfs: fix status accounting for lost cluster chains

checklost() scans for lost cluster chains and attempts to
repair each one, first by reconnecting it to LOST.DIR,
and falling back to clearing it if reconnection fails.
However, checklost() incorrectly updates the modification
status flags (mod), which checkfilesys() relies on to
determine whether to write back changes and what exit
status to return.

The current code have three issues:

1. A reconnect() failure immediately sets FSERROR in mod
   via "mod |= ret = reconnect(...)".  If reconnect() failed
   (e.g., because LOST.DIR is missing, or full) but the
   fallback clear operation succeeds, clearchain() frees the
   chain and sets FSFATMOD.  However, the leftover FSERROR
   remains in mod: checkfilesys() skips marking the file system
   clean and exits with status 8, even though the file system was
   fully repaired and a subsequent run finds nothing left to do.
   This can happen with "fsck_msdosfs -y" on a volume without
   LOST.DIR.

2. The same assignment overwrites checkchain()'s return value
   before it can be recorded in mod.  When checkchain()
   truncates a chain (e.g., one whose tail points to a free
   cluster), its FSFATMOD status is lost, causing checkfilesys()
   to skip updating the FAT and discard the truncation.
   With LOST.DIR present so that reconnect() succeeds,
   "fsck_msdosfs -y" reports "Truncate? yes" and "FILE SYSTEM WAS
   MODIFIED", exits 0, but leaves the identical damage on disk
   to be found again on every subsequent run.  Similarly, an
   FSFATAL return value from checkchain() is dropped, defeating
   the "if (mod & FSFATAL) break" guard that follows.

3. When checkchain() returns FSERROR and clearing the chain is
   declined, no error status is recorded in mod, causing fsck_msdosfs
   to report a clean exit despite leaving un-repaired damage.

Fix these issues by:

 - Merge checkchain()'s status into mod before calling reconnect(),
   and skip reconnect() if checkchain() returned a fatal error.
 - Defer recording FSERROR from a failed reconnect() until after the
   Clear fallback attempt, setting FSERROR only if the chain remains
   unhandled.

MFC after:      1 week
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2251

0 files changed, 0 insertions, 0 deletions