Fixture creation in `gix-status-tests` fails with `PermissionDenied` for `unreadable_untracked` fixture

[cruessler]

I’ve come across an issue related to fixture creation triggered by a test in gix-status-tests.

Steps to reproduce (update 2026-04-28)

In the gitoxide repo, on commit 4d5ba23.

rm -rf gix-status/tests/fixtures/generated-archives

cargo nextest run -p gix-status-tests --features gix-features-parallel --no-fail-fast

I’ve been running this because my go-to command for testing whether generating fixtures for a specific crate works is:

# this removes both `generated-fixtures` as well as `generated-do-not-edit`
# I run this to make sure `SHA-256` fixtures are generated for the PRs that add
# running tests with `SHA-256`
rm -rf gix-status/tests/fixtures/generated-*

Usually, this makes the tests just recreate both directories. In this very specific case, though, unreadable_untracked.tar, is in gix-status/tests/fixtures/generated-archives/.gitignore, and on my Linux machine, I get a test that fails with:

        FAIL [   0.020s] gix-status-tests::status index_as_worktree_with_renames::unreadable_untracked
  stdout ───

    running 1 test
    test index_as_worktree_with_renames::unreadable_untracked ... FAILED

    failures:

    failures:
        index_as_worktree_with_renames::unreadable_untracked

    test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 30 filtered out; finished in 0.02s

  stderr ───
    Archive at 'fixtures/generated-archives/unreadable_untracked.tar' not found, creating fixture using script 'unreadable_untracked.sh'

    thread 'index_as_worktree_with_renames::unreadable_untracked' (206767) panicked at gix-status/tests/status/mod.rs:21:6:
    script works: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }

All other tests gix-status-tests are passing, it’s just this specific test that’s failing.

From what I can tell, this is the line the error happens in:

gitoxide/tests/tools/src/lib.rs

Line 1467 in 4d5ba23

ar.append_dir_all(".", source_dir)?;

[Byron]

Thanks for reporting!

It's related to rm -Rf also deleting a .gitignore file in generated-archives whose absence then causes the tar file that shouldn't be generated, to be generated, with the known failure as a file in there can't be traversed.

I use gix clean -xd '**generated-do-not-edit/', and maybe that can be adjusted to also clear out what you want cleaned?

Maybe gix clean -xdm '**generated-do-not-edit/' '**generated-archives/*.tar' '**generated-archives/*.tar.xz' is what you want.

It doesn't look like this is actionable here though.

Codex

I think it’s a real bug, and the root cause is simpler than the PermissionDenied makes it look.

The issue’s cleanup command deletes:

rm -rf gix-status/tests/fixtures/generated-archives

That directory contains the tracked ignore rule:

gix-status/tests/fixtures/generated-archives/.gitignore
unreadable_untracked.tar

That ignore rule is what tells tests/tools/src/lib.rs not to create an archive for unreadable_untracked.tar. Once the whole directory is removed, the rule is gone, so create_archive_if_we_should() no longer skips archive creation. It then calls tar::Builder::append_dir_all(".", source_dir) over a fixture containing chmod 000 unreadable, and that fails with PermissionDenied.

I verified:

• At the reported commit 4d5ba231685e8ff36195603c57193aa1cd21fa8e, the focused test reproduces after deleting generated-archives.
• Current local HEAD 048e8dff287ce56412f17986c5d8b5f1b76dc42a still reproduces the same failure.
• If the ignore rule is moved up to gix-status/tests/fixtures/.gitignore as:

generated-archives/unreadable_untracked.tar

then deleting generated-archives no longer removes the rule, and the focused test passes.

My preferred fix would be to move the ignore rule out of the generated directory:

• Add gix-status/tests/fixtures/.gitignore with generated-archives/unreadable_untracked.tar
• Remove gix-status/tests/fixtures/generated-archives/.gitignore

That matches the intended behavior with minimal code change. A broader testtools fix is possible, but this specific failure is caused by putting policy for a generated path inside the generated path itself.

Issue inspected: #2548