Skip to content

Emit tar -C option before the source operands in archive.tar (fixes #57847)#69236

Open
ggiesen wants to merge 1 commit into
saltstack:3006.xfrom
ggiesen:fix-57847-archive-tar-c-order
Open

Emit tar -C option before the source operands in archive.tar (fixes #57847)#69236
ggiesen wants to merge 1 commit into
saltstack:3006.xfrom
ggiesen:fix-57847-archive-tar-c-order

Conversation

@ggiesen
Copy link
Copy Markdown
Contributor

@ggiesen ggiesen commented May 27, 2026

What does this PR do?

Fixes archive.tar emitting the -C <dest> directory-change option after the source/member operands. tar (GNU, BSD and macOS) treats -C as positional in both create and extract modes -- it only affects the operands that follow it -- so when it is placed last it silently has no effect, or errors on newer GNU tar:

tar: -C '/tmp/foo/bar' has no effect
tar: Exiting with failure status due to previous errors

The option is now emitted before the operands so it takes effect.

What issues does this PR fix or reference?

Fixes #57847

That issue was reported against genesis.pack, which called archive.tar(..., sources=".", dest=root) and ended up archiving the wrong directory (root's home) because -C root came after the . operand. genesis has since been removed from Salt core (dc526dc, "Initial purge of community extensions"), but the underlying archive.tar bug -- which is the root cause the reporter identified -- is still present and affects any create-with-dest call, or extraction of specific members into a dest directory.

Previous Behavior

archive.tar("jpcf", "/srv/img/foo.tar.bz2", ".", dest="/tmp/foo/bar")
# -> tar jpcf /srv/img/foo.tar.bz2 . -C /tmp/foo/bar   (-C ignored)

-C after the operands is ignored (or fatal on newer GNU tar), so the wrong directory is packed/extracted.

New Behavior

archive.tar("jpcf", "/srv/img/foo.tar.bz2", ".", dest="/tmp/foo/bar")
# -> tar jpcf /srv/img/foo.tar.bz2 -C /tmp/foo/bar .   (-C honored)

The documented extract-into-dest case with no source members (tar xf foo.tar dest=/d -> tar xf foo.tar -C /d) is byte-for-byte unchanged.

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

  • Docs
  • Changelog - changelog/57847.fixed.md
  • Tests written/updated - tests/pytests/unit/modules/test_archive.py (test_tar_dest_precedes_sources_on_create, ..._on_extract, test_tar_dest_without_sources; verified the two ordering tests fail on current master and pass with this change, with no change to the existing test_tar)

Commits signed with GPG?

No

archive.tar appended "-C <dest>" after the source/member operands. tar
(GNU, BSD and macOS) treats -C as positional in create and extract modes:
it only affects the operands that follow it, so placing it last silently
had no effect, or errored on newer GNU tar. This is the root cause behind
the genesis.pack failure reported in saltstack#57847. genesis has since been removed
from Salt core, but the archive.tar bug remains and breaks any pack with a
dest, or extraction of specific members into a dest directory.

Emit "-C <dest>" before the operands so it takes effect. The documented
extract-into-dest case (no source members) is byte-for-byte unchanged.
@ggiesen ggiesen force-pushed the fix-57847-archive-tar-c-order branch from 4df88f5 to 901be04 Compare May 27, 2026 15:38
@ggiesen ggiesen changed the base branch from master to 3006.x May 27, 2026 15:38
@ggiesen
Copy link
Copy Markdown
Contributor Author

ggiesen commented May 27, 2026

Re-targeted to 3006.x (was master): this is a bug fix and 3006.x is the oldest supported branch that contains the affected archive.tar code, per Salt's contributing guide. It will merge forward to 3007.x/3008.x/master.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[BUG] genesis.pack tar arguments in wrong order

1 participant