Never scan an operand inside a .zfs directory (closes #142)
check / check (push) Waiting to run
check / check (push) Waiting to run
An operand inside a directory named .zfs was walked, because the operand check looked only at the operand's own name. The check now also looks at every directory above the operand, both as given and with its symlinks resolved. Such an operand gets a warning, counts as skipped and is not walked, whether given alone or under another operand. The check runs before overlapping operands are pruned, so an operand under another one still gets its warning. The test for an operand named .zfs now writes its record beneath .zfs straight into the database, since no scan stores one there any more. Judgement call: a path component named .zfs counts whatever it is, a symlink included. Model: opus-5-5
This commit is contained in:
@@ -461,17 +461,26 @@ exclude, is not on a persistent filesystem (see "Rules for the walk"), or, with
|
||||
`-x`, is on a different filesystem than that operand, because that operand's
|
||||
walk does not enter such a directory and so does not reach 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
|
||||
a one-line warning naming the path and what it is, counts it as skipped, and
|
||||
drops it from the scanned operands before reading the database. Another operand
|
||||
beneath it is still scanned. The records stored beneath it are not deleted: they
|
||||
are treated like any other record outside the scanned operands. If it lies under
|
||||
another operand, they are under that operand instead, and are treated like any
|
||||
other record there. This is not an error: a scan whose every operand is dropped
|
||||
walks nothing and exits 0. An operand that is not on a persistent filesystem
|
||||
(see "Rules for the walk") is dropped the same way. The line `scan` prints for
|
||||
it is not a warning, though, and it is not counted as skipped.
|
||||
An operand is not scanned when it is:
|
||||
|
||||
- a symlink, which `scan` never follows, not even as an operand;
|
||||
- a socket, FIFO or device node;
|
||||
- at or inside a directory named `.zfs`.
|
||||
|
||||
An operand reached through a symlink into a `.zfs` directory is not scanned
|
||||
either.
|
||||
|
||||
This holds even when the operand lies under another operand. `scan` prints a
|
||||
one-line warning naming the path and what it is, counts it as skipped, and drops
|
||||
it from the scanned operands before reading the database. An operand beneath a
|
||||
symlink operand is still scanned. The records stored beneath the dropped operand
|
||||
are not deleted: they are treated like any other record outside the scanned
|
||||
operands. If it lies under another operand, they are under that operand instead,
|
||||
and are treated like any other record there. This is not an error: a scan whose
|
||||
every operand is dropped walks nothing and exits 0. An operand that is not on a
|
||||
persistent filesystem (see "Rules for the walk") is dropped the same way. The
|
||||
line `scan` prints for it is not a warning, though, and it is not counted as
|
||||
skipped.
|
||||
|
||||
`scan` synchronizes the database with the filesystem state under the scanned
|
||||
operands:
|
||||
|
||||
Reference in New Issue
Block a user