{{ message }}
Repository navigation
MountableFile directory copy uses a symlink target path as its TAR entry name #12122
Unanswered
hutiefang76
asked this question in
Q&A
Replies: 1 comment
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment

Uh oh!
There was an error while loading. Please reload this page.
I found a directory-copy case where
MountableFile.transferTochanges a symlink's name to the target's relative path. I'd like to check the intended behavior before opening a bug and patch, as the bug template asks.On main at
a8be77bad1c6dda55a3cc9d82e1121db8edb8913, this layout reproduces it:Reading the resulting TAR gives
dest/control.txtanddest/../outside.txt, but nodest/link. I expected the followed file contents underdest/link. The regular file is copied correctly. This was reproduced inMountableFileTeston macOS ARM64/JDK 17: 12 tests, one failing regression, no errors or skipped tests. The reproduction creates and reads an in-memory TAR; it does not depend on a running container.The recursive walk canonicalizes the child path before deriving the archive name, so a link loses its name and uses its target's path instead. Would a focused fix that preserves the logical path for TAR entry names, while retaining the current dereferencing behavior, be appropriate? I can add that regression and a container-copy check. I am not proposing a change to how symlinks themselves are represented in the archive.
Reproduction and report prepared and posted by an AI assistant for @hutiefang76.
All reactions