fix(du): use getdents64 on Linux to avoid EOVERFLOW on 32-bit architectures

[mattsu2020]

Summary

• Fix du producing "Value too large for defined data type" (EOVERFLOW) on 32-bit Linux (i686) when reading directories
• Replace nix::dir::Dir (which calls libc::readdir() with 32-bit d_ino) with rustix::fs::RawDir (which calls getdents64 syscall with 64-bit d_ino/d_off) on Linux/Android
• This also fixes all other utilities using DirFd::read_dir(): rm, chmod, chown, install

Root Cause

On 32-bit glibc, libc::readdir() uses struct dirent with 32-bit d_ino. Modern filesystems (XFS, Btrfs, ext4+inode64) can return inode numbers exceeding 2^32, causing EOVERFLOW.

Fix

Use rustix::fs::RawDir on Linux which calls the getdents64 syscall directly, always using 64-bit directory entry fields. rustix with fs feature is already an unconditional dependency of uucore, so no new dependencies are needed.

On non-Linux Unix (macOS, BSDs), the existing nix::dir::Dir implementation is retained.

Test

• cargo check -p uucore passes
• cargo check -p uu_du passes
• cargo test -p uu_du — all tests pass
• cargo test -p uu_rm — all tests pass
• cargo test -p uu_chmod — all tests pass
• cargo test -p coreutils -- du — all 112 du integration tests pass

Closes #11848

[codspeed-hq]

Merging this PR will improve performance by 40.59%

⚠️ 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

⚡ 6 improved benchmarks
✅ 303 untouched benchmarks
⏩ 46 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	Simulation	du_max_depth_balanced_tree[(6, 4, 10)]	25.1 ms	20.4 ms	+23.02%
⚡	Simulation	du_wide_tree[(5000, 500)]	9.2 ms	8.2 ms	+12.14%
⚡	Simulation	du_deep_tree[(100, 3)]	1,089.6 µs	998.3 µs	+9.15%
⚡	Simulation	du_summarize_balanced_tree[(5, 4, 10)]	6.6 ms	5.3 ms	+24.25%
⚡	Simulation	du_all_wide_tree[(5000, 500)]	16.2 ms	15 ms	+7.68%
⚡	Simulation	rm_recursive_tree	11.9 ms	8.5 ms	+40.59%

---

_{Comparing mattsu2020:du_fix (4c574da) with main (30fd234)}

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. ↩

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/cut/bounded-memory (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/rm/isatty (fails in this run but passes in the 'main' branch)
Note: The gnu test tests/tail/tail-n0f is now being skipped but was previously passing.
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM is now passing!

[oech3]

Merging this PR will improve performance by 40.59%

What happened?

[oech3]

Would you add comment why cannot we use rustix at other unix?
Is it able to request API to rustix's upstream?

[xtqqczze]

⚡ Simulation rm_recursive_tree 11.9 ms 8.5 ms +40.59%

@oech3 The benchmark contains 46897 system calls in HEAD but 70335 system calls in BASE. Since system calls are not instrumented in CodSpeed, be careful interpreting this result.

[oech3]

perf is near with mimalloc. Does mimalloc increase num of syscalls too by same reason with this?

[xtqqczze]

perf is near with mimalloc. Does mimalloc increase num of syscalls too by same reason with this?

70334 system calls with mimalloc (#11866) so no change

[xtqqczze]

@oech Could you run benchmarks with hyperfine?

[xtqqczze]

In general please use full URL instead of (Issue #11848). But since this PR will close that issue I think you could remove the reference.

[xtqqczze]

@mattsu2020 please clean your commit history