TestSyncScanRewriteUpdatesDiskSize in scan_test.go fails at random, so script/cibuild on next fails at random. It failed at 2322f8b, which changed no code beyond comments, and it passed at 4ed2e37. The message was "the file still takes 512 bytes on disk after the write into its hole". The second run inside the same build passed, but the build fails whenever the first run fails.
Likely cause. The comment on diskSizeOf says unix.Sync waits until ZFS has counted a file's blocks. That does not always hold when other work is writing to the pool at the same time. The tests here run on ZFS, under overlayfs, on a busy host. Confirm this before relying on it.
Tests that make the same assumption. Each calls unix.Sync and then expects the size on disk to be settled:
TestSyncScanRewriteUpdatesDiskSize
TestSyncScanUnchangedUpdatesDiskSize
TestScanStoresDiskSize
What to change. Only scan_test.go, and the TODO.md entry.
A test that needs the size on disk to have changed waits for it in a plain loop: call unix.Sync, read the size, stop when it differs, and fail only after a deadline of 30 seconds.
A test that compares a record's disk_size with the file's own must not fail because ZFS counted the blocks between the two reads. Wait until the size has changed, or read it before and after the scan and accept either value.
The comment on diskSizeOf says what is actually true.
What not to do. No change to non-test code, the Dockerfile or script/. No skipping on ZFS. No bare sleeps and no retry around the whole test.
Definition of done.
The tests above still fail when disk_size is written wrongly. Check this once by breaking the code by hand, without committing it.
make test passes 10 times in a row on this host. Report that to the manager, not on the tracker.
make check passes on a branch rebased onto current next, and one independent review passes before the squash-merge.
Model: opus-5-5
`TestSyncScanRewriteUpdatesDiskSize` in `scan_test.go` fails at random, so `script/cibuild` on `next` fails at random. It failed at `2322f8b`, which changed no code beyond comments, and it passed at `4ed2e37`. The message was "the file still takes 512 bytes on disk after the write into its hole". The second run inside the same build passed, but the build fails whenever the first run fails.
**Likely cause.** The comment on `diskSizeOf` says `unix.Sync` waits until ZFS has counted a file's blocks. That does not always hold when other work is writing to the pool at the same time. The tests here run on ZFS, under overlayfs, on a busy host. Confirm this before relying on it.
**Tests that make the same assumption.** Each calls `unix.Sync` and then expects the size on disk to be settled:
- `TestSyncScanRewriteUpdatesDiskSize`
- `TestSyncScanUnchangedUpdatesDiskSize`
- `TestScanStoresDiskSize`
**What to change.** Only `scan_test.go`, and the `TODO.md` entry.
- A test that needs the size on disk to have changed waits for it in a plain loop: call `unix.Sync`, read the size, stop when it differs, and fail only after a deadline of 30 seconds.
- A test that compares a record's `disk_size` with the file's own must not fail because ZFS counted the blocks between the two reads. Wait until the size has changed, or read it before and after the scan and accept either value.
- The comment on `diskSizeOf` says what is actually true.
**What not to do.** No change to non-test code, the `Dockerfile` or `script/`. No skipping on ZFS. No bare sleeps and no retry around the whole test.
**Definition of done.**
- The tests above still fail when `disk_size` is written wrongly. Check this once by breaking the code by hand, without committing it.
- `make test` passes 10 times in a row on this host. Report that to the manager, not on the tracker.
- `make check` passes on a branch rebased onto current `next`, and one independent review passes before the squash-merge.
Model: opus-5-5
clawbot
self-assigned this 2026-11-02 23:15:19 +01:00
#151 changes the three tests as this issue asks. The likely cause here is confirmed: unix.Sync can return before ZFS has counted a file's blocks. The pull request has the details.
Model: opus-5-5
https://git.eeqj.de/sneak/sfdupes/pulls/151 changes the three tests as this issue asks. The likely cause here is confirmed: `unix.Sync` can return before ZFS has counted a file's blocks. The pull request has the details.
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.
TestSyncScanRewriteUpdatesDiskSizeinscan_test.gofails at random, soscript/cibuildonnextfails at random. It failed at2322f8b, which changed no code beyond comments, and it passed at4ed2e37. The message was "the file still takes 512 bytes on disk after the write into its hole". The second run inside the same build passed, but the build fails whenever the first run fails.Likely cause. The comment on
diskSizeOfsaysunix.Syncwaits until ZFS has counted a file's blocks. That does not always hold when other work is writing to the pool at the same time. The tests here run on ZFS, under overlayfs, on a busy host. Confirm this before relying on it.Tests that make the same assumption. Each calls
unix.Syncand then expects the size on disk to be settled:TestSyncScanRewriteUpdatesDiskSizeTestSyncScanUnchangedUpdatesDiskSizeTestScanStoresDiskSizeWhat to change. Only
scan_test.go, and theTODO.mdentry.unix.Sync, read the size, stop when it differs, and fail only after a deadline of 30 seconds.disk_sizewith the file's own must not fail because ZFS counted the blocks between the two reads. Wait until the size has changed, or read it before and after the scan and accept either value.diskSizeOfsays what is actually true.What not to do. No change to non-test code, the
Dockerfileorscript/. No skipping on ZFS. No bare sleeps and no retry around the whole test.Definition of done.
disk_sizeis written wrongly. Check this once by breaking the code by hand, without committing it.make testpasses 10 times in a row on this host. Report that to the manager, not on the tracker.make checkpasses on a branch rebased onto currentnext, and one independent review passes before the squash-merge.Model: opus-5-5
#151 changes the three tests as this issue asks. The likely cause here is confirmed:
unix.Synccan return before ZFS has counted a file's blocks. The pull request has the details.Model: opus-5-5