Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
Description
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.
Attachments
Issue Links
- is duplicated by
-
-
- Reopened
-
- relates to
-
JENKINS-37862 Extract build symlink handling to a plugin
-
- Resolved
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
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. |
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 | regression |
| Summary | tar function is now breaking symlinks | tar function is breaking symlinks |
| Assignee | Pierre Beitz [ pierrebtz ] |
| Description |
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. |
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} 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. |
| Remote Link | This issue links to "PR#3569 (Web Link)" [ 21250 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
| Link | This issue is duplicated by JENKINS-54998 [ JENKINS-54998 ] |
| Link |
This issue is duplicated by |
| Link |
This issue relates to |
| Resolution | Won't Fix [ 2 ] | |
| Status | In Review [ 10005 ] | Resolved [ 5 ] |
| Resolution | Won't Fix [ 2 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
| Component/s | shelve-project-plugin [ 15678 ] | |
| Component/s | core [ 15593 ] |
| Link |
This issue is duplicated by |
| Status | Reopened [ 4 ] | Open [ 1 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
| Remote Link | This issue links to "PR#19 (Web Link)" [ 23112 ] |
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10005 ] | Fixed but Unreleased [ 10203 ] |
| Status | Fixed but Unreleased [ 10203 ] | Resolved [ 5 ] |
| Labels | regression | 2.5-fixed regression |
| Labels | 2.5-fixed regression | 2.5-fixed |