The test-case assertion forces the creation of a source file that will be opened and used for the delta, but deletes it from the source directory right before .\tar-patch is run.
mkdir -p "$TEST_DIR/solo/data" "$TEST_DIR/solom/data" head -c 4096 /dev/zero >"$TEST_DIR/solo/data/only.txt" cp -a "$TEST_DIR/solo/data/only.txt" "$TEST_DIR/solom/data/only.txt" printf 'patched' | dd of="$TEST_DIR/solom/data/only.txt" bs=1 seek=2000 conv=notrunc status=none 2>/dev/null || \ printf 'patched' | dd of="$TEST_DIR/solom/data/only.txt" bs=1 seek=2000 conv=notrunc 2>/dev/null create_tar "$TEST_DIR/solo-old.tar" "$TEST_DIR/solo" create_tar "$TEST_DIR/solo-new.tar" "$TEST_DIR/solom" ./tar-diff -max-bsdiff-size 64 "$TEST_DIR/solo-old.tar.gz" "$TEST_DIR/solo-new.tar.bz2" "$TEST_DIR/solo.tardiff" rm -f "$TEST_DIR/solo/data/only.txt" if [[ -e "$TEST_DIR/solo/data/only.txt" ]]; then echo "expected solo/data/only.txt removed before tar-patch" >&2 exit 1 fi expect_fail "tar-patch missing source member" ./tar-patch "$TEST_DIR/solo.tardiff" "$TEST_DIR/solo" "$TEST_DIR/solo-out.tar"
All other runners successfully pass this test except for the Windows runner on GitHub Actions. To verify the tar-patch behavior on Windows, a Windows Server 2025 environment was set up locally on a virtual machine. Once the source file is deleted for testing purposes, we get the following error message:
Error applying diff: open extracted\test_dir\only.txt: The system cannot find the file specified.
On local Windows Server, the tool correctly displays the error message and exits with code 1 (failure). However, in the Windows CI environment, tar-patch exits with code 0 (success), causing the test to fail with: expected failure for: tar-patch missing source member.With both reconstructed.tar and original.tar SHA sums differing, this proves the patch application was unsuccessful and should have exited with
code 1.
In addition to investigating why the Windows CI environment exits with code 0 when local Windows correctly exits with code 1, a cleanup mechanism should also be implemented to remove malformed outputs. This will ensure users are not left with the impression that the tool succeeded when it didn't.
The current resolution is to skip this test on Windows while we investigate this issue.
The test-case assertion forces the creation of a source file that will be opened and used for the delta, but deletes it from the source directory right before
.\tar-patchis run.mkdir -p "$TEST_DIR/solo/data" "$TEST_DIR/solom/data" head -c 4096 /dev/zero >"$TEST_DIR/solo/data/only.txt" cp -a "$TEST_DIR/solo/data/only.txt" "$TEST_DIR/solom/data/only.txt" printf 'patched' | dd of="$TEST_DIR/solom/data/only.txt" bs=1 seek=2000 conv=notrunc status=none 2>/dev/null || \ printf 'patched' | dd of="$TEST_DIR/solom/data/only.txt" bs=1 seek=2000 conv=notrunc 2>/dev/null create_tar "$TEST_DIR/solo-old.tar" "$TEST_DIR/solo" create_tar "$TEST_DIR/solo-new.tar" "$TEST_DIR/solom" ./tar-diff -max-bsdiff-size 64 "$TEST_DIR/solo-old.tar.gz" "$TEST_DIR/solo-new.tar.bz2" "$TEST_DIR/solo.tardiff" rm -f "$TEST_DIR/solo/data/only.txt" if [[ -e "$TEST_DIR/solo/data/only.txt" ]]; then echo "expected solo/data/only.txt removed before tar-patch" >&2 exit 1 fi expect_fail "tar-patch missing source member" ./tar-patch "$TEST_DIR/solo.tardiff" "$TEST_DIR/solo" "$TEST_DIR/solo-out.tar"All other runners successfully pass this test except for the Windows runner on GitHub Actions. To verify the tar-patch behavior on Windows, a Windows Server 2025 environment was set up locally on a virtual machine. Once the source file is deleted for testing purposes, we get the following error message:
Error applying diff: open extracted\test_dir\only.txt: The system cannot find the file specified.On local Windows Server, the tool correctly displays the error message and exits with code 1 (failure). However, in the Windows CI environment, tar-patch exits with code 0 (success), causing the test to fail with:
expected failure for: tar-patch missing source member.With bothreconstructed.tarandoriginal.tarSHA sums differing, this proves the patch application was unsuccessful and should have exited withcode 1.
In addition to investigating why the Windows CI environment exits with code 0 when local Windows correctly exits with code 1, a cleanup mechanism should also be implemented to remove malformed outputs. This will ensure users are not left with the impression that the tool succeeded when it didn't.
The current resolution is to skip this test on Windows while we investigate this issue.