Walk an operand nested on another filesystem with -x (closes #106)
check / check (push) Canceled after 0s

With -x, an operand under another operand is kept when it is on a
different filesystem than the deepest kept operand above it, because
that operand's walk does not enter it; it is then walked on its own.
Below such an operand, the rule that keeps the records under a
directory -x did not enter applies only to directories its own walk
did not enter, so the records of files gone from it are deleted.

The new test stubs each operand's device and shares its scan steps
with the test for #99, whose
comment no longer claims it runs every phase. The startWalk comment is
rewrapped.

Model: opus-5-5
This commit is contained in:
2026-10-14 18:37:06 +00:00
parent 80bd7c0999
commit e248313ed1
4 changed files with 212 additions and 44 deletions
+5 -2
View File
@@ -398,7 +398,9 @@ results do not depend on the working directory. All operands belong to a single
scan and are enumerated concurrently: every operand seeds the shared walk worker
pool. Overlapping operands are harmless — an operand that duplicates another or
lies under another is dropped before walking, so every file is reached exactly
once and produces one database record.
once and produces one database record. With `-x`, though, an operand under
another one is kept and walked on its own when it is on a different filesystem
than the operand covering it, because that operand's walk does not enter it.
An operand that is a symlink (never followed, not even as an operand), socket,
FIFO, or device node, or a directory named `.zfs`, is not scanned. `scan` prints
@@ -451,7 +453,8 @@ operands:
directory is on another filesystem than its operand counts as outside the
scanned operands: it is not deleted, and its size joins the size census. A
filesystem mounted under an operand can therefore be scanned on its own
schedule into the same database.
schedule into the same database. Records below an operand inside such a
directory are not kept this way, since that operand's own walk verifies them.
`scan` runs **four sequential phases over the whole scan**. Parallelism lives
inside each phase; batched database writes begin during the hash phase: