-
Bug
-
Resolution: Fixed
-
Major
While debugging the shelve plugin I noticed that the tar function available in the FilePath class is not conserving the symlinks anymore. The shelve plugin is calling the archive function in FilePath:
archive(final ArchiverFactory factory, OutputStream os, final DirScanner scanner) // factory use is TarArchiverFactory with no compression
Both tar archiving function do not properly handle the symlinks to directory (but it works correctly for symlinks to files):
* public int tar(OutputStream out, final String glob) -> uses a DirScanner.Glob (ant style FileSets) that follows the symlink, therefore creates a brand new directory in place of the symlink, not what we want for a tar archive.
* public int tar(OutputStream out, FileFilter filter) -> uses a FileFilter wrapper which for some reasons doesn't redirect the symlink calls to the wrapped FileFilter
Why this is important: this issue has been here for long, but a change made on 2.91 (see my comment below for Issue 2), made this appear more clearly.
- is duplicated by
-
JENKINS-54998 Stash and archive should refuse symlinks
-
- Reopened
-
- relates to
-
JENKINS-37862 Extract build symlink handling to a plugin
-
- Resolved
-
- links to
[JENKINS-52781] tar function is breaking symlinks
Description |
Original:
While debugging the shelve plugin I noticed that the tar function available in the FilePath class is not conserving the symlinks anymore. The shelve plugin is calling the archive function in FilePath the factory being the TarArchiverFactory with no compression: {code:java} archive(final ArchiverFactory factory, OutputStream os, final DirScanner scanner){code} I did several experiment, and ended up narrowing the issue to the release 2.91. It's still not working in the latest weekly (2.134). In the release notes of 2.91, I saw the following that might (or might not) be the cause of this issue: {noformat} Use Java NIO library instead of native code to create and detect symbolic links and Windows junctions to improve compatibility and robustness. {noformat} I'm not sure I'll have time this week end to have a look, but I can for sure provide a non working unit test next week if needed. |
New:
While debugging the shelve plugin I noticed that the tar function available in the FilePath class is not conserving the symlinks anymore. The shelve plugin is calling the archive function in FilePath: {code:java} archive(final ArchiverFactory factory, OutputStream os, final DirScanner scanner) // factory use is TarArchiverFactory with no compression{code} I did several experiment, and ended up narrowing the issue to the release 2.91. It's still not working in the latest weekly (2.134). In the release notes of 2.91, I saw the following that might (or might not) be the cause of this issue: {noformat} Use Java NIO library instead of native code to create and detect symbolic links and Windows junctions to improve compatibility and robustness. {noformat} I'm not sure I'll have time this week end to have a look, but I can for sure provide a non working unit test next week if needed. |
Labels | New: regression |
Summary | Original: tar function is now breaking symlinks | New: tar function is breaking symlinks |
Assignee | New: Pierre Beitz [ pierrebtz ] |
pierrebtz Did you bisect the issue to exactly 2.91? The changes in 2.91 should have only changed the happy-path behavior on Windows, unless maybe Files#isSymbolicLink is returning false for the link in question but the getCanonicalPath fallbacks removed in 2.91 would have identified it as a symlink.
However, 2.93 changed changed whether this call would include non-basic-permission bits in the mode (i.e. previously it would include file type and setuid/setgid bits, but afterwards it only includes read/write/execute bits). I am curious to see if a patch like the following fixes the issue: