truncate: fix a minor nit + add a hole-punching test

[kevans]

Summary

The struct spacectl_range we use is only really used in these three
lines of code, so re-scope it down to just the dealloc branch. This is
marginally easier to reason about what might be necessary to replace in
porting our truncate(1) to other platforms.

While we're here, add a test for the -d flag to be sure it really does
punch a hole in the file. The test also tries to confirm that it does
not disturb other segments of the file in the process, just to inspire
some confidence that it's not corrupting the file somehow.

Sponsored by: Klara, Inc.

[kevans]

Fix a few nits upon post-review-creation-review

[des]

usr.bin/truncate/tests/lssparse.c

1 ↗

(On Diff #158175)

This largely duplicates bin/cp/tests/sparse.c.

[kevans]

usr.bin/truncate/tests/lssparse.c

1 ↗

(On Diff #158175)

I mean, they're both fairly trivial (and this particular one is an extract of the larger "mksparse" that I wrote for openrsync to additionally build out and sparsify files) - I need actual reporting of all the holes, not just whether there's any hole, and also the extra bits to decide the hole size. I could enhance that one, but where would you suggest placing it instead? Reaching into bin/cp/tests feels a bit wrong.

[markj]

usr.bin/truncate/tests/truncate_test.sh

454

Rather than filling a file using /dev/zero, can you use /dev/random to defeat the compression? In general it's nice to use the native filesystem when possible, so we get different test coverage depending on the filesystem in use. I run the test suite on both UFS and ZFS, for instance.

[des]

usr.bin/truncate/tests/lssparse.c

1 ↗

(On Diff #158175)

Perhaps we should just add this functionality to stat(1)...

[kevans]

Address review feedback; use stat -h and stop asserting on hole reporting

We'll still want stat -h to tell us the min hole size that we're working with,
but stop testing for hole reporting and just test that the segment has been
zeroed out. Many modern filesystems make this complicated as they have creative
license to deallocate as much or as little as they want; we can make the request
to deallocate a block and they will zero it out, but they may choose to keep the
block allocated for whatever reason.

Switch to just ensuring that the requested block is zeroed out without
collateral damage.