Open mkitti opened 6 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
6269b5b
) 97.28% compared to head (0bcb514
) 97.64%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Can the julia compat and CI tests be bumped to 1.6?
Adding the following test results in a stack overflow.
tarball, io = mktemp()
tar_write_link(io, "a", "b/q")
tar_write_link(io, "b", "a/q")
close(io)
Tar.tree_hash(tarball; copy_symlinks=true)
The following test results in a stack overflow from a different function:
tarball, io = mktemp()
tar_write_dir(io, "foo/bar")
tar_write_link(io, "foo/bar/b", "../a")
tar_write_link(io, "foo/a", "bar/")
close(io)
Tar.tree_hash(tarball; copy_symlinks=true)
What does extract do in this circumstance?
extract has a stack overflow in the first case and goes into an infinite loop in the second case.
We should determine the correct behavior for extract
first. My sense is that it should produce a more intuitive and descriptive error.
That makes sense, though sometimes extract
will ignore symlinks that it cannot copy. This might be the same issue as https://github.com/JuliaIO/Tar.jl/issues/77 . Maybe these issues could be resolved while doing the refactoring described in https://github.com/JuliaIO/Tar.jl/issues/64
Yeah, this is a known issue for extract: https://github.com/JuliaIO/Tar.jl/issues/77. I just never got around to fixing it because it seems deeply unlikely in real-world tarballs, but of course, we should handle it correctly. But it's very annoying to fix.
Implement
copy_symlinks
keyword forTar.tree_hash
For https://github.com/JuliaLang/Pkg.jl/issues/3643 https://github.com/JuliaBinaryWrappers/P4est_jll.jl/releases/download/P4est-v2.8.1+2/P4est.v2.8.1.x86_64-w64-mingw32-mpi+microsoftmpi.tar.gz
For https://github.com/JuliaPackaging/Yggdrasil/issues/7888 https://github.com/JuliaBinaryWrappers/iso_codes_jll.jl/releases/download/iso_codes-v4.11.0+0/iso_codes.v4.11.0.any.tar.gz