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.

       

          [JENKINS-52781] tar function is breaking symlinks

          Pierre Beitz created issue -
          Pierre Beitz made changes -
          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.

           
          Daniel Beck made changes -
          Labels New: regression
          Pierre Beitz made changes -
          Summary Original: tar function is now breaking symlinks New: tar function is breaking symlinks
          Pierre Beitz made changes -
          Assignee New: Pierre Beitz [ pierrebtz ]
          Pierre Beitz made changes -
          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:
          {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.

           
          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}
           

          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.

           
          Pierre Beitz made changes -
          Remote Link New: This issue links to "PR#3569 (Web Link)" [ 21250 ]
          Pierre Beitz made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]
          Pierre Beitz made changes -
          Status Original: In Progress [ 3 ] New: In Review [ 10005 ]
          Andrew Bayer made changes -
          Link New: This issue is duplicated by JENKINS-54998 [ JENKINS-54998 ]
          Andrew Bayer made changes -
          Link New: This issue is duplicated by JENKINS-55560 [ JENKINS-55560 ]

            pierrebtz Pierre Beitz
            pierrebtz Pierre Beitz
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: