* .github/workflows/GnuTests.yml (Fetch reference results): Retry the
branch lookup and treat only a 404 as "nothing published yet"; a
transient API error used to look like a missing baseline and silently
skip both comparisons, letting a regression through unnoticed.
(Publish to the reference branch): Same for the published run id, which
guards the force-push. A suppressed error read as run id 0 would let
this run overwrite a reference a newer run had already placed.
* .github/workflows/NotifyTracking.yml: Do not name a cadence for the
tracking repository's fallback schedule, which is its own to change.
* .github/workflows/GnuTests.yml (Fetch reference results): Resolve the
reference branch tip once and read every file at that commit. The
branch is force-pushed by 'publish-reference', so reading each file by
branch name could straddle a publish and pair one file with another
reference's, comparing against a baseline that never existed.
* .github/workflows/NotifyTracking.yml (jobs.dispatch.if): Dispatch for
any completed run, not only a successful one. 'GnuTests' uploads its
results and only then fails the comparison when it finds a new failure,
and 'publish-reference' publishes regardless, so requiring success left
the graphs un-refreshed for exactly the regressions they exist to show.
* .github/workflows/NotifyTracking.yml (jobs.dispatch.env): Add
HAVE_APP_CREDENTIALS; the 'secrets' context is not available in a step's
'if:', where it fails with "Unrecognized named-value: 'secrets'", so the
check has to go through a job-level env var.
* .github/workflows/GnuTests.yml (jobs.publish-reference.concurrency):
Serialize publishing. The step reads the published run id and then
force-pushes, so two overlapping runs could interleave those and let an
older one overwrite a newer reference.
* .github/workflows/NotifyTracking.yml: New workflow sending a
repository_dispatch to uutils/coreutils-tracking once 'GnuTests' or
'make' has finished on the default branch.
The tracking repository polled our artifacts on a cron, so its graphs
lagged the data by up to six hours. Telling it when the data is ready
lets it refresh immediately; its schedule stays as a safety net.
A GITHUB_TOKEN only covers the repository it runs in, so this needs a
credential of its own: an organization-owned GitHub App installed on the
tracking repository, read from the TRACKING_APP_ID and
TRACKING_APP_PRIVATE_KEY secrets. Without them the step warns and the
tracking repository keeps refreshing on its own schedule.
* .github/workflows/GnuTests.yml (env): Add REFERENCE_BRANCH.
(on.push.branches): Exclude the reference branch, which carries no code.
(aggregate): Fetch the reference from that branch rather than resolving
and downloading a workflow artifact.
(publish-reference): New job publishing this run's results on a push to
the default branch.
An artifact is addressable only by run id, so finding one meant listing
workflow runs on the default branch. That listing's 'branch' filter is
served by an eventually consistent index which intermittently returns a
snapshot weeks out of date, making every test fixed on the default
branch since then look like a fix contributed by the pull request.
- Add conditional compilation for WASI target to avoid panics from `std::env::temp_dir()`
- Implement fallback logic in `Options` to read TMPDIR environment variable directly on WASI
- Update `get_tmpdir_env_or_default()` with WASI-specific handling for temp directory resolution
- Add `#[cfg_attr]` annotations to skip host path-dependent tests on WASI sandbox environment
- Ignore 14 tests that require host filesystem access when running under wasi_runner
- Ignore directory permission test on WASI due to lack of `chmod` support and mode parameter limitations
cp treats ENOSYS like EOPNOTSUPP when skipping optional attribute
preservation (WASI has no chmod/chown at all), reads timestamps via
Metadata::accessed/modified instead of the filetime crate (which
panics there), and only errors out of --reflink when explicitly
requested rather than whenever it isn't Never.
Replace the onig C-dependency in expr with the pure-Rust fancy-regex crate.
This removes the onig_sys C library dependency while preserving full POSIX BRE,
backreference, multibyte UTF-8, and C locale compatibility.
The instrumented aarch64-pc-windows-msvc binary writes .profraw files that llvm-profdata rejects with "symbol name is empty" (rust-lang/rust#150123, rust-lang/rust#156675). The job keeps building natively, without PGO.
mv already holds the invariant: it has its own cross-device fallback
rather than cp's copy machinery, so it never had the three-open problem.
These pin it in place, since the pending fd-anchored rework of the EXDEV
directory path (GHSA-pp2g) touches exactly this code.
Three assertions: a same-filesystem move must open the source zero times
(it is a rename, not a copy), and the cross-device file and directory
fallbacks must open each source exactly once. Each was verified to fail
by injecting a redundant File::open at the matching call site.
The directory case matches any path ending in the source name opened
O_RDONLY, so it keeps working once the traversal opens by bare name
under a directory fd. Cross-device needs a second filesystem; /dev/shm
supplies it, and the checks skip loudly when it shares a device with
TEMP_DIR rather than passing vacuously.
New util/check-open-once.sh straces cp and asserts the source path is
opened exactly once, across the default, --sparse=always and
--sparse=never paths. Verified it fails on the previous code with 'opened
the source 3 times', so it guards the invariant rather than restating it.
Kept out of check-toctou.sh: no exploit is known for the old window --
every open used the same credentials and flags -- and the security
scripts should stay about attacker-exploitable splits. The new header
says so and points at the two that do.
Traces open(2) as well as openat(2): rustix issues the former on Linux,
so an openat-only filter matches nothing and passes vacuously.
xtqqczze
Sylvestre Ledru
oech3
renovate[bot]
Eduardo Rodrigues
Daniel Hofstetter
wtcpython
Anthony