tail:Fix tail -f sparse file growth handling

[mattsu2020]

Summary

Fixes tail -f behavior when a followed sparse file grows by a very large amount, such as via truncate -s 1P.

The follow path previously used BytesChunkBuffer::new(u64::MAX), which consumed all newly readable bytes into memory before printing. For sparse file holes, those bytes are read as NULs, so a large logical size increase could cause tail to consume excessive memory and get killed.

This changes follow-mode output to read one chunk to detect whether new data exists and preserve header behavior, then stream the remaining data directly to stdout with io::copy.

Fixes #12015.

Validation

• cargo fmt --check
• cargo check -p uu_tail
• cargo test -p uu_tail
• cargo build -p coreutils
• cargo test --test tests test_n0_with_follow --features tail
• Manual sparse growth check with tail -n0 -f --use-polling and truncate -s 1P

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM is now passing!

[xtqqczze]

make this a named function?

[Alonely0]

I'm not even sure there was a need for that in the first place... this is a weird JS idiom that popped up after I noped out of there. The new added function looks fine tho.

[codspeed-hq]

Merging this PR will degrade performance by 3.11%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

❌ 1 regressed benchmark
✅ 310 untouched benchmarks
⏩ 46 skipped benchmarks¹

⚠️ Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	du_max_depth_balanced_tree[(6, 4, 10)]	25 ms	25.8 ms	-3.11%

---

_{Comparing mattsu2020:tail_12015 (628aee0) with main (45a48a1)}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩