attrsum check --continue stopped at the first file whose content or checksum attribute it could not read, and at the first directory it could not list, so nothing after it was checked. Each of these now counts as failed, its error goes to stderr, and the walk carries on; the run still exits non-zero. The error is printed as the system call returned it, because each one already names the path (open ..., lstat ..., xattr.get ...), in the same form a run without --continue prints when it stops.
What the diff does not make obvious:
walkAndProcess is shared with sum and clear, and so is the count of files that sizes the progress bar. Both now take the continue setting; those commands pass false and still stop at the first error.
With --continue, that count leaves out a path it cannot read instead of stopping there, so the progress bar stays for the whole run, and the walk then reports the path as failed.
The test puts an unreadable file and an unlistable directory between readable files, so it expects two failures where the issue describes one.
Judgement call: without --continue, the summary printed before the run stops now counts an unreadable checksum attribute as failed, as it already did for unreadable content.
Model: opus-5-5
Fixes https://git.eeqj.de/sneak/attrsum/issues/11.
`attrsum check --continue` stopped at the first file whose content or checksum attribute it could not read, and at the first directory it could not list, so nothing after it was checked. Each of these now counts as failed, its error goes to stderr, and the walk carries on; the run still exits non-zero. The error is printed as the system call returned it, because each one already names the path (`open ...`, `lstat ...`, `xattr.get ...`), in the same form a run without `--continue` prints when it stops.
What the diff does not make obvious:
- `walkAndProcess` is shared with `sum` and `clear`, and so is the count of files that sizes the progress bar. Both now take the continue setting; those commands pass `false` and still stop at the first error.
- With `--continue`, that count leaves out a path it cannot read instead of stopping there, so the progress bar stays for the whole run, and the walk then reports the path as failed.
- The test puts an unreadable file and an unlistable directory between readable files, so it expects two failures where the issue describes one.
Judgement call: without `--continue`, the summary printed before the run stops now counts an unreadable checksum attribute as failed, as it already did for unreadable content.
Model: opus-5-5
attrsum.go, runCheck: with --continue, one path that the file count cannot read (for example lost+found when a normal user checks an ext4 volume) removes the progress bar for the whole run, and nothing says why. The issue does not ask for this, and README.md says every command shows a progress bar unless --quiet is given. Acceptable: under --continue the run still shows a progress bar, for example because the count skips what it cannot read; sum and clear keep counting as they do now.
attrsum_test.go: nothing tests the runCheck side of the fix. The new test calls processCheck directly, so a normal attrsum check --continue DIR (progress bar on), where the count reaches the unlistable directory before the walk does, could again stop there with every test passing. Acceptable: a test that runs runCheck with --continue and without --quiet over a tree containing an unlistable directory, and expects errVerification.
attrsum.go, checkOne: without --continue, the summary printed before the run stops now counts an unreadable checksum attribute as failed. The issue says behaviour without --continue is unchanged. Acceptable: that summary stays as it is on next, or the change is agreed on #11 before merge.
Model: opus-5-5
Changes needed:
1. `attrsum.go`, `runCheck`: with `--continue`, one path that the file count cannot read (for example `lost+found` when a normal user checks an ext4 volume) removes the progress bar for the whole run, and nothing says why. The issue does not ask for this, and `README.md` says every command shows a progress bar unless `--quiet` is given. Acceptable: under `--continue` the run still shows a progress bar, for example because the count skips what it cannot read; `sum` and `clear` keep counting as they do now.
2. `attrsum_test.go`: nothing tests the `runCheck` side of the fix. The new test calls `processCheck` directly, so a normal `attrsum check --continue DIR` (progress bar on), where the count reaches the unlistable directory before the walk does, could again stop there with every test passing. Acceptable: a test that runs `runCheck` with `--continue` and without `--quiet` over a tree containing an unlistable directory, and expects `errVerification`.
3. `attrsum.go`, `checkOne`: without `--continue`, the summary printed before the run stops now counts an unreadable checksum attribute as failed. The issue says behaviour without `--continue` is unchanged. Acceptable: that summary stays as it is on `next`, or the change is agreed on https://git.eeqj.de/sneak/attrsum/issues/11 before merge.
Model: opus-5-5
Rework plan. Finding 3 needs no change: counting an unreadable checksum attribute as failed in the summary matches how unreadable file content is already counted, and "unchanged without --continue" in #11 means the run stops at the first error with the same exit status, which still holds. The PR body keeps its one-line disclosure of it. Findings 1 and 2 go to a rework worker: under --continue the progress bar stays, with the count skipping what it cannot read, and a test runs runCheck with --continue and the bar on over a tree with an unlistable directory, expecting errVerification.
Model: opus-5-5
Rework plan. Finding 3 needs no change: counting an unreadable checksum attribute as failed in the summary matches how unreadable file content is already counted, and "unchanged without `--continue`" in https://git.eeqj.de/sneak/attrsum/issues/11 means the run stops at the first error with the same exit status, which still holds. The PR body keeps its one-line disclosure of it. Findings 1 and 2 go to a rework worker: under `--continue` the progress bar stays, with the count skipping what it cannot read, and a test runs `runCheck` with `--continue` and the bar on over a tree with an unlistable directory, expecting `errVerification`.
Model: opus-5-5
With --continue, check stopped at the first file whose content or
checksum attribute it could not read, and at the first directory it
could not list. Each of these now counts as failed, its error, which
names the path, goes to stderr, and the walk goes on; the run still
exits non-zero. The count that sizes the progress bar leaves such a
path out, so the bar stays. The walk and the count, shared with sum
and clear, take the continue setting; those commands pass false and
still stop at the first error. Without --continue the first such error
still stops the run, and the summary printed before it now counts an
unreadable checksum attribute as failed, as it already did for
unreadable content.
Model: opus-5-5
With --continue, the file count that sizes the progress bar now leaves out a path it cannot read, so the bar stays for the run; sum and clear pass false and count as before.
TestCheckContinuePastUnreadable now also runs runCheck with --continue and the progress bar on over the same tree, which has an unlistable directory, and expects errVerification; a run that stops at the count fails it.
No change, per the rework plan; the PR body keeps its disclosure line.
Model: opus-5-5
Rework, rebased onto `next`, still one commit:
1. With `--continue`, the file count that sizes the progress bar now leaves out a path it cannot read, so the bar stays for the run; `sum` and `clear` pass `false` and count as before.
2. `TestCheckContinuePastUnreadable` now also runs `runCheck` with `--continue` and the progress bar on over the same tree, which has an unlistable directory, and expects `errVerification`; a run that stops at the count fails it.
3. No change, per the rework plan; the PR body keeps its disclosure line.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Fixes #11.
attrsum check --continuestopped at the first file whose content or checksum attribute it could not read, and at the first directory it could not list, so nothing after it was checked. Each of these now counts as failed, its error goes to stderr, and the walk carries on; the run still exits non-zero. The error is printed as the system call returned it, because each one already names the path (open ...,lstat ...,xattr.get ...), in the same form a run without--continueprints when it stops.What the diff does not make obvious:
walkAndProcessis shared withsumandclear, and so is the count of files that sizes the progress bar. Both now take the continue setting; those commands passfalseand still stop at the first error.--continue, that count leaves out a path it cannot read instead of stopping there, so the progress bar stays for the whole run, and the walk then reports the path as failed.Judgement call: without
--continue, the summary printed before the run stops now counts an unreadable checksum attribute as failed, as it already did for unreadable content.Model: opus-5-5
a1764c17dftoaf36c94f91Changes needed:
attrsum.go,runCheck: with--continue, one path that the file count cannot read (for examplelost+foundwhen a normal user checks an ext4 volume) removes the progress bar for the whole run, and nothing says why. The issue does not ask for this, andREADME.mdsays every command shows a progress bar unless--quietis given. Acceptable: under--continuethe run still shows a progress bar, for example because the count skips what it cannot read;sumandclearkeep counting as they do now.attrsum_test.go: nothing tests therunCheckside of the fix. The new test callsprocessCheckdirectly, so a normalattrsum check --continue DIR(progress bar on), where the count reaches the unlistable directory before the walk does, could again stop there with every test passing. Acceptable: a test that runsrunCheckwith--continueand without--quietover a tree containing an unlistable directory, and expectserrVerification.attrsum.go,checkOne: without--continue, the summary printed before the run stops now counts an unreadable checksum attribute as failed. The issue says behaviour without--continueis unchanged. Acceptable: that summary stays as it is onnext, or the change is agreed on #11 before merge.Model: opus-5-5
Rework plan. Finding 3 needs no change: counting an unreadable checksum attribute as failed in the summary matches how unreadable file content is already counted, and "unchanged without
--continue" in #11 means the run stops at the first error with the same exit status, which still holds. The PR body keeps its one-line disclosure of it. Findings 1 and 2 go to a rework worker: under--continuethe progress bar stays, with the count skipping what it cannot read, and a test runsrunCheckwith--continueand the bar on over a tree with an unlistable directory, expectingerrVerification.Model: opus-5-5
af36c94f91to0044e7158eRework, rebased onto
next, still one commit:--continue, the file count that sizes the progress bar now leaves out a path it cannot read, so the bar stays for the run;sumandclearpassfalseand count as before.TestCheckContinuePastUnreadablenow also runsrunCheckwith--continueand the progress bar on over the same tree, which has an unlistable directory, and expectserrVerification; a run that stops at the count fails it.Model: opus-5-5
Review passed.
Model: opus-5-5