GNU Coreutils 9.12 speeds up cut and uniq and fixes a recursive traversal race

September 14, 2026. GNU Coreutils 9.12 lands on the official GNU site. 4×. That is the throughput gain claimed for cut -w on typical inputs. 2026. A competing rewrite in Rust, uutils, keeps maturing at the same time. Why it matters: ls, cp, cut, sort and uniq ship in every container image and every shell script on the planet, and how this foundation evolves directly concerns administrators and distribution maintainers alike.

The release matters less for any single headline feature than for what it signals: the C codebase at the bottom of the Linux stack is still being actively optimized and hardened, even as the ecosystem debates whether Rust should eventually replace it.

The measured performance wins

Coreutils 9.12 is not a flashy release, but it quantifies its progress, which is rare for a maintenance drop. Three optimizations stand out:

• cut -w gains up to 4× throughput on typical inputs. For anyone slicing whitespace-delimited columns out of large logs, that is pipeline time recovered directly.
• uniq -c is up to 2.5× faster on systems where stdio functions are unlocked — occurrence counting, a building block of log analysis, benefits from it.
• sort makes better use of available memory and parallelism when reading from an unknown-size input such as a pipe. That is the most common case in practice, and precisely where the previous heuristics were conservative.

These numbers are not anecdotal. Across a fleet that processes terabytes of logs a day, a two-fold speedup on uniq -c or a four-fold one on cut -w translates into CPU time and observability latency, without changing a single line of script.

The --reflink=auto case deserves a note. On copy-on-write filesystems such as Btrfs or reflink-enabled XFS, cp --reflink=auto attempts a near-instant copy by sharing blocks. When that attempt fails — for example because an XFS allocation group’s metadata space is exhausted — the old behavior could fail the whole copy. The automatic fallback to a standard copy makes the behavior more predictable: the copy completes, at the cost of disk space.

The race fixed on recursive options

The most interesting fix concerns a long-standing bug: chcon, chgrp, chmod, chown, du and ls would fail while traversing hierarchies with the recursive -R option when files were deleted in parallel. The symptom — an error return code or an aborted traversal — appeared on live trees, exactly the ones found in shared directories or concurrent builds.

This kind of race is the signature of software written for a world where the filesystem stays static while you walk it, when it never does. The fix makes recursive commands reliable in environments where other processes write and delete during the walk — a case CI/CD pipelines and build clusters know well.

This fix directly concerns backup and synchronization tools that rely on cp -R, chown -R or du to walk live trees. A du that fails mid-count, or a cp -R that aborts because a file was deleted in parallel, skews results without always being detected. Concurrent backup systems — those that capture volumes while writes continue — are the first beneficiaries.

New options and new filesystems

The release also adds a few functional items:

• uname -A (or --all-labeled): prints everything with one label per line, a more parseable output for scripts that read uname.
• stat and tail now recognize the FailFS and NULLFS filesystem types, useful in test environments and synthetic mounts.
• cp, install and mv fall back to a standard copy when --reflink=auto fails for various reasons — for example on XFS when a clone exhausts an allocation group’s metadata space.
• mv now warns when copying an extended attribute fails, instead of failing silently or masking the loss.

There are also quiet fixes: a possible buffer over-read in factor, several Solaris-specific bugs, and assorted tweaks. Nothing dramatic, but each item hardens tools that are expected to never surprise you.

For operators, the practical takeaway is modest but real: uname -A gives scripts a machine-readable, labeled output instead of the traditional space-separated blob, and the FailFS/NULLFS support removes a class of edge-case failures in test harnesses that mount synthetic filesystems. Neither is headline material; both are the kind of quiet compatibility work that keeps a decades-old toolkit from becoming a surprise generator.

Coreutils’ place in the ecosystem

GNU Coreutils is not the only implementation of the basic commands. BusyBox provides a compact version for embedded systems and minimal images — it is what you find in Alpine Linux. The BSDs maintain their own versions of ls, cp and sort. But the GNU version is the compatibility reference: its options, its behavior and its exit codes are what scripts assume by default.

That position explains why a maintenance release interests so many people. A behavior change in cp or sort propagates through entire chains of tools, from Makefiles to data pipelines. It is also why GNU Coreutils moves slowly: stability is a product in itself, and every added option — like uname -A — must coexist with decades of scripts that parse the existing output.

GNU in C against the Rust rewrite

The context makes this release more interesting than it looks. Alongside GNU Coreutils, the uutils coreutils project rewrites the same toolkit in Rust, arguing for memory safety and a modern approach. ETTAYEB has already documented this trajectory: where GNU banks on decades of stability and compatibility, uutils gains ground on resilience against memory bugs.

This 9.12 illustrates what the C path still produces: targeted optimizations (cut, uniq, sort) and race fixes that demand deep knowledge of system calls. It also illustrates its limit — a race left open for years before being addressed. For distributions and image maintainers, the question is not picking a side, but knowing when the Rust version will reach enough coverage to become the credible default alternative. Until then, Coreutils 9.12 remains what we deploy everywhere.

This tension, ETTAYEB has already explored in its analysis of Rust Coreutils 0.10: the uutils rewrite is closing the gap on option coverage and memory safety, but the GNU version keeps the edge on maturity and absolute compatibility. For container images, the stakes are concrete: Debian and Ubuntu ship GNU Coreutils, while Alpine prefers BusyBox for size. Version 9.12 does not change that split, but it strengthens the case for GNU in images where option conformance and pipeline performance matter more than a few megabytes.

Verdict

GNU Coreutils 9.12 is a maintenance release that will not change your life, but it quietly improves the foundation everything else rests on.

If you process large volumes of logs or text data, try cut -w and uniq -c on 9.12: the throughput gains are measurable without migrating scripts. If you maintain distributions or container images, pull this version as soon as it reaches your repositories, if only for the -R race fix that affects recursive walks in concurrent environments. If you are tracking the rise of the Rust rewrite, keep this release in mind as a benchmark of what the C version still does well, while uutils keeps closing its gap.

References

• Phoronix — GNU Coreutils 9.12 Released With Performance Optimizations, New uname Option
• LWN — GNU Core Utilities 9.12 released
• GNU — Coreutils 9.12
• uutils/coreutils — the Rust rewrite of the GNU toolkit