[bet4it]

Summary

In scan::tests::disk_usage_is_whole_allocation_units, fs::write performs asynchronous buffered I/O without flushing dirty pages to storage (fsync).

On Copy-on-Write filesystems with delayed allocation (such as OpenZFS), newly written asynchronous blocks remain in dirty transaction groups (TXG) in memory before commit. An immediate stat() call on the written file reports st_blocks = 1 (accounting only for the inode/bonus buffer, or 512 bytes), causing scan_dir to read tree.bytes = 512 and failing the assertion:

thread 'scan::tests::disk_usage_is_whole_allocation_units' panicked at crates/disktree-core/src/scan.rs:1652:9:
512

This caused CI build failures when building packages in environments using ZFS build scratch pools (e.g. NixOS Hydra CI build 347804046).

Changes

• Replace fs::write with File::create, write_all, followed by file.sync_all() (fsync).
• Explicitly drop(file) before invoking scan_dir.
• Add a comment explaining the delayed allocation behavior on CoW/ZFS filesystems.

Verification

Verified both locally and inside an isolated NixOS QEMU VM running an OpenZFS pool configured with compression and POSIX ACLs:

• Without sync_all: st_blocks = 1, tree.bytes = 512 (panics with 512).
• With sync_all: st_blocks = 197 (100,864 bytes), test passes.
• cargo xtask lint and cargo xtask test pass cleanly.