Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-52781

tar function is breaking symlinks

    XMLWordPrintable

    Details

    • Similar Issues:

      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

            Activity

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

             
            danielbeck Daniel Beck made changes -
            Labels regression
            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            Pierre Beitz 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:

            diff --git a/core/src/main/java/hudson/util/io/TarArchiver.java b/core/src/main/java/hudson/util/io/TarArchiver.java
            index 5d97aaa43b..0fdddc44ec 100644
            --- a/core/src/main/java/hudson/util/io/TarArchiver.java
            +++ b/core/src/main/java/hudson/util/io/TarArchiver.java
            @@ -64,7 +64,7 @@ final class TarArchiver extends Archiver {
                     try {
                         int mode = IOUtils.mode(link);
                         if (mode != -1) {
            -                e.setMode(mode);
            +                e.setMode(0120000 | mode); // 0120000 is the file mode for a symbolic link.
                         }
                     } catch (PosixException x) {
                         // ignore
            
            Show
            dnusbaum Devin Nusbaum added a comment - - edited Pierre Beitz 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: diff --git a/core/src/main/java/hudson/util/io/TarArchiver.java b/core/src/main/java/hudson/util/io/TarArchiver.java index 5d97aaa43b..0fdddc44ec 100644 --- a/core/src/main/java/hudson/util/io/TarArchiver.java +++ b/core/src/main/java/hudson/util/io/TarArchiver.java @@ -64,7 +64,7 @@ final class TarArchiver extends Archiver { try { int mode = IOUtils.mode(link); if (mode != -1) { - e.setMode(mode); + e.setMode(0120000 | mode); // 0120000 is the file mode for a symbolic link. } } catch (PosixException x) { // ignore
            Hide
            pierrebtz Pierre Beitz added a comment - - edited

            Devin Nusbaum

            I did some additional tests and found out that the issue I found, was already present, but was outlined by another one (or a behavior change?) introduced in 2.91. Here are the details:

            Issue 1: tar breaking the symlinks (not a regression, at least since 2.60)

            This is the issue I initially reported, except it's not a regression. I found out that a symlink to a directory is tarred into a directory. Here is a unit test outlining that. Note that the test is red since 2.60 at least:

             

            import hudson.FilePath;
            import org.junit.Assert;
            import org.junit.Rule;
            import org.junit.rules.TemporaryFolder;
            
            import java.io.IOException;
            import java.io.OutputStream;
            import java.nio.file.Files;
            import java.nio.file.Path;
            import java.nio.file.Paths;
            
            public class Test {
            
                @Rule
                public TemporaryFolder folder= new TemporaryFolder();
            
                @org.junit.Test
                public void aSymlinkToADirectoryFails() throws IOException, InterruptedException {
                    Path folderToTar = folder.newFolder().toPath();
                    Path subdirectory = Files.createDirectory(folderToTar.resolve("subdirectory"));
                    Path targetDirectory = subdirectory.resolve("1");
                    Files.createDirectory(targetDirectory);
                    Files.createFile(targetDirectory.resolve("oneFile"));
                    Path link = Files.createSymbolicLink(subdirectory.resolve("link"), Paths.get("1"));
                    Assert.assertTrue(Files.isSymbolicLink(link));
            
                    Path tarFile = folderToTar.resolve("archive.tar");
                    FilePath tarFilePath = new FilePath(tarFile.toFile());
            
                    try (OutputStream os = tarFilePath.write()) {
                        new FilePath( folderToTar.toFile()).tar(os, "**/*");
                    }
            
                    Path untarredFolder = folder.getRoot().toPath().resolve("untarredFolder");
            
                    tarFilePath.untar(new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE);
            
                    Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve("subdirectory/link")));
            
                }
            
                @org.junit.Test
                public void aSymlinkToAFileWorks() throws IOException, InterruptedException {
                    Path folderToTar = folder.newFolder().toPath();
                    Path subdirectory = Files.createDirectory(folderToTar.resolve("subdirectory"));
                    Path targetFile = subdirectory.resolve("1");
                    Files.createFile(targetFile);
                    Path link = Files.createSymbolicLink(subdirectory.resolve("link"), Paths.get("1"));
                    Assert.assertTrue(Files.isSymbolicLink(link));
            
                    Path tarFile = folderToTar.resolve("archive.tar");
                    FilePath tarFilePath = new FilePath(tarFile.toFile());
            
                    try (OutputStream os = tarFilePath.write()) {
                        new FilePath( folderToTar.toFile()).tar(os, "**/*");
                    }
            
                    Path untarredFolder = folder.getRoot().toPath().resolve("untarredFolder");
            
                    tarFilePath.untar(new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE);
            
                    Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve("subdirectory/link")));
            
                }
            }
            

            Issue 2: behavior change in 2.91

            The shelve plugin is using the tar function we just saw to archive job directories. Upon unarchiving, a job directory looks therefore like this:

            drwxr-xr-x  7 pierrebeitz  staff  224 27 jul 23:50 .
            drwxr-xr-x  7 pierrebeitz  staff  224 27 jul 23:50 ..
            drwxr-xr-x  9 pierrebeitz  staff  288 27 jul 23:50 builds
            -rw-r--r--  1 pierrebeitz  staff  497 27 jul 23:42 config.xml
            drwxr-xr-x  5 pierrebeitz  staff  160 27 jul 23:50 lastStable
            drwxr-xr-x  5 pierrebeitz  staff  160 27 jul 23:50 lastSuccessful
            -rw-r--r--  1 pierrebeitz  staff    2 27 jul 23:42 nextBuildNumber
            

            Instead of:

            drwxr-xr-x  7 pierrebeitz  staff  224 27 jul 23:42 .
            drwxr-xr-x  7 pierrebeitz  staff  224 27 jul 23:44 ..
            drwxr-xr-x  9 pierrebeitz  staff  288 27 jul 23:42 builds
            -rw-r--r--  1 pierrebeitz  staff  497 27 jul 23:42 config.xml
            lrwxr-xr-x  1 pierrebeitz  staff   22 27 jul 23:42 lastStable -> builds/lastStableBuild
            lrwxr-xr-x  1 pierrebeitz  staff   26 27 jul 23:42 lastSuccessful -> builds/lastSuccessfulBuild
            -rw-r--r--  1 pierrebeitz  staff    2 27 jul 23:42 nextBuildNumber

             

            The thing is, before 2.91, when launching a new run of the job, Jenkins was somehow capable of deleting those directories and recreating the symlinks.

            Now, it is unable of doing so:

            ln builds/lastSuccessfulBuild ***/jenkins-home/jobs/toto/lastSuccessful failed
            java.nio.file.DirectoryNotEmptyException: ***/jenkins-home/jobs/toto/lastSuccessful
            	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
            	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
            	at java.nio.file.Files.deleteIfExists(Files.java:1165)
            	at hudson.Util.createSymlink(Util.java:1333)
            	at hudson.model.Run.createSymlink(Run.java:1866)
            	at hudson.model.Run.updateSymlinks(Run.java:1847)
            	at hudson.model.Run.execute(Run.java:1725)
            	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
            	at hudson.model.ResourceController.execute(ResourceController.java:97)
            	at hudson.model.Executor.run(Executor.java:421)

             

            As the job directory is not supposed to be in this state, I can understand that this behavior change is not necessarily a bug. However the first issue looks like a bug.

            Show
            pierrebtz Pierre Beitz added a comment - - edited Devin Nusbaum I did some additional tests and found out that the issue I found, was already present, but was outlined by another one (or a behavior change?) introduced in 2.91. Here are the details: Issue 1: tar breaking the symlinks (not a regression, at least since 2.60) This is the issue I initially reported, except it's not a regression. I found out that a symlink to a directory is tarred into a directory. Here is a unit test outlining that. Note that the test is red since 2.60 at least:   import hudson.FilePath; import org.junit.Assert; import org.junit.Rule; import org.junit.rules.TemporaryFolder; import java.io.IOException; import java.io.OutputStream; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; public class Test { @Rule public TemporaryFolder folder= new TemporaryFolder(); @org.junit.Test public void aSymlinkToADirectoryFails() throws IOException, InterruptedException { Path folderToTar = folder.newFolder().toPath(); Path subdirectory = Files.createDirectory(folderToTar.resolve( "subdirectory" )); Path targetDirectory = subdirectory.resolve( "1" ); Files.createDirectory(targetDirectory); Files.createFile(targetDirectory.resolve( "oneFile" )); Path link = Files.createSymbolicLink(subdirectory.resolve( "link" ), Paths.get( "1" )); Assert.assertTrue(Files.isSymbolicLink(link)); Path tarFile = folderToTar.resolve( "archive.tar" ); FilePath tarFilePath = new FilePath(tarFile.toFile()); try (OutputStream os = tarFilePath.write()) { new FilePath( folderToTar.toFile()).tar(os, "**/*" ); } Path untarredFolder = folder.getRoot().toPath().resolve( "untarredFolder" ); tarFilePath.untar( new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE); Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve( "subdirectory/link" ))); } @org.junit.Test public void aSymlinkToAFileWorks() throws IOException, InterruptedException { Path folderToTar = folder.newFolder().toPath(); Path subdirectory = Files.createDirectory(folderToTar.resolve( "subdirectory" )); Path targetFile = subdirectory.resolve( "1" ); Files.createFile(targetFile); Path link = Files.createSymbolicLink(subdirectory.resolve( "link" ), Paths.get( "1" )); Assert.assertTrue(Files.isSymbolicLink(link)); Path tarFile = folderToTar.resolve( "archive.tar" ); FilePath tarFilePath = new FilePath(tarFile.toFile()); try (OutputStream os = tarFilePath.write()) { new FilePath( folderToTar.toFile()).tar(os, "**/*" ); } Path untarredFolder = folder.getRoot().toPath().resolve( "untarredFolder" ); tarFilePath.untar( new FilePath(untarredFolder.toFile()), FilePath.TarCompression.NONE); Assert.assertTrue(Files.isSymbolicLink(untarredFolder.resolve( "subdirectory/link" ))); } } Issue 2: behavior change in 2.91 The shelve plugin is using the tar function we just saw to archive job directories. Upon unarchiving, a job directory looks therefore like this: drwxr-xr-x 7 pierrebeitz staff 224 27 jul 23:50 . drwxr-xr-x 7 pierrebeitz staff 224 27 jul 23:50 .. drwxr-xr-x 9 pierrebeitz staff 288 27 jul 23:50 builds -rw-r--r-- 1 pierrebeitz staff 497 27 jul 23:42 config.xml drwxr-xr-x 5 pierrebeitz staff 160 27 jul 23:50 lastStable drwxr-xr-x 5 pierrebeitz staff 160 27 jul 23:50 lastSuccessful -rw-r--r-- 1 pierrebeitz staff 2 27 jul 23:42 nextBuildNumber Instead of: drwxr-xr-x 7 pierrebeitz staff 224 27 jul 23:42 . drwxr-xr-x 7 pierrebeitz staff 224 27 jul 23:44 .. drwxr-xr-x 9 pierrebeitz staff 288 27 jul 23:42 builds -rw-r--r-- 1 pierrebeitz staff 497 27 jul 23:42 config.xml lrwxr-xr-x 1 pierrebeitz staff 22 27 jul 23:42 lastStable -> builds/lastStableBuild lrwxr-xr-x 1 pierrebeitz staff 26 27 jul 23:42 lastSuccessful -> builds/lastSuccessfulBuild -rw-r--r-- 1 pierrebeitz staff 2 27 jul 23:42 nextBuildNumber   The thing is, before 2.91, when launching a new run of the job, Jenkins was somehow capable of deleting those directories and recreating the symlinks. Now, it is unable of doing so: ln builds/lastSuccessfulBuild ***/jenkins-home/jobs/toto/lastSuccessful failed java.nio.file.DirectoryNotEmptyException: ***/jenkins-home/jobs/toto/lastSuccessful at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242) at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108) at java.nio.file.Files.deleteIfExists(Files.java:1165) at hudson.Util.createSymlink(Util.java:1333) at hudson.model.Run.createSymlink(Run.java:1866) at hudson.model.Run.updateSymlinks(Run.java:1847) at hudson.model.Run.execute(Run.java:1725) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:421)   As the job directory is not supposed to be in this state, I can understand that this behavior change is not necessarily a bug. However the first issue looks like a bug.
            Hide
            dnusbaum Devin Nusbaum added a comment -

            My guess is that before 2.91, this code was executed if the path for the new symlink was currently a directory, but now we just call Files#deleteIfExists, which fails for directories. We could reintroduce similar behavior so that things would work the same as before 2.91, but as you noted that wouldn't fix the main issue.

            Show
            dnusbaum Devin Nusbaum added a comment - My guess is that before 2.91, this code was executed if the path for the new symlink was currently a directory, but now we just call Files#deleteIfExists , which fails for directories. We could reintroduce similar behavior so that things would work the same as before 2.91, but as you noted that wouldn't fix the main issue.
            Hide
            pierrebtz Pierre Beitz added a comment - - edited

            Devin Nusbaum

             

            I dig a bit deeper on the symlink issue. It turns out that if ant is set to follow the symlinks, it will consider a symlink to a directory as a 'normal directory' when creating the FileSet, therefore, there is no way for the callee to know afterward if a directory is a real one or not (ant code here

             

            I found out that asking ant not to follow the symlink, I could then retrieve them on a separate collection in the FileSet and treat them myself. Here is a small patch demonstrating what I'm saying:

             

            Index: core/src/main/java/hudson/util/DirScanner.java
            IDEA additional info:
            Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
            <+>UTF-8
            ===================================================================
            --- core/src/main/java/hudson/util/DirScanner.java	(revision 94abd9119082211e24b1bffc6d33d6905446ef08)
            +++ core/src/main/java/hudson/util/DirScanner.java	(date 1532794865000)
            @@ -8,6 +8,7 @@
             import java.io.FileFilter;
             import java.io.IOException;
             import java.io.Serializable;
            +import java.nio.file.Paths; import static hudson.Util.fixEmpty;@@ -29,6 +30,11 @@
                  * @since 1.532
                  */
                 protected final void scanSingle(File f, String relative, FileVisitor visitor) throws IOException {
            +        if (scanSymlink(f, relative, visitor)) return;
            +        visitor.visit(f, relative);
            +    }
            +
            +    protected boolean scanSymlink(File f, String relative, FileVisitor visitor) throws IOException {
                     if (visitor.understandsSymlink()) {
                         String target;
                         try {
            @@ -38,10 +44,10 @@
                         }
                         if (target != null) {
                             visitor.visitSymlink(f, target, relative);
            -                return;
            +                return true;
                         }
                     }
            -        visitor.visit(f, relative);
            +        return false;
                 }     /**
            @@ -120,7 +126,12 @@
                         fs.setDefaultexcludes(useDefaultExcludes);             if(dir.exists()) {
            +                fs.setFollowSymlinks(false);
                             DirectoryScanner ds = fs.getDirectoryScanner(new org.apache.tools.ant.Project());
            +                for(String f: ds.getNotFollowedSymlinks()) {
            +                    File file = dir.toPath().relativize(Paths.get(f)).toFile();
            +                    scanSymlink(new File(f), file.getPath(), visitor);
            +                }
                             for( String f : ds.getIncludedFiles()) {
                                 File file = new File(dir, f);
                                 scanSingle(file, f, visitor);

             

             

            Show
            pierrebtz Pierre Beitz added a comment - - edited Devin Nusbaum   I dig a bit deeper on the symlink issue. It turns out that if ant is set to follow the symlinks, it will consider a symlink to a directory as a 'normal directory' when creating the FileSet, therefore, there is no way for the callee to know afterward if a directory is a real one or not ( ant code here   I found out that asking ant not to follow the symlink, I could then retrieve them on a separate collection in the FileSet and treat them myself. Here is a small patch demonstrating what I'm saying:   Index: core/src/main/java/hudson/util/DirScanner.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== --- core/src/main/java/hudson/util/DirScanner.java (revision 94abd9119082211e24b1bffc6d33d6905446ef08) +++ core/src/main/java/hudson/util/DirScanner.java (date 1532794865000) @@ -8,6 +8,7 @@ import java.io.FileFilter; import java.io.IOException; import java.io.Serializable; + import java.nio.file.Paths; import static hudson.Util.fixEmpty;@@ -29,6 +30,11 @@ * @since 1.532 */ protected final void scanSingle(File f, String relative, FileVisitor visitor) throws IOException { + if (scanSymlink(f, relative, visitor)) return ; + visitor.visit(f, relative); + } + + protected boolean scanSymlink(File f, String relative, FileVisitor visitor) throws IOException { if (visitor.understandsSymlink()) { String target; try { @@ -38,10 +44,10 @@ } if (target != null ) { visitor.visitSymlink(f, target, relative); - return ; + return true ; } } - visitor.visit(f, relative); + return false ; } /** @@ -120,7 +126,12 @@ fs.setDefaultexcludes(useDefaultExcludes); if (dir.exists()) { + fs.setFollowSymlinks( false ); DirectoryScanner ds = fs.getDirectoryScanner( new org.apache.tools.ant.Project()); + for ( String f: ds.getNotFollowedSymlinks()) { + File file = dir.toPath().relativize(Paths.get(f)).toFile(); + scanSymlink( new File(f), file.getPath(), visitor); + } for ( String f : ds.getIncludedFiles()) { File file = new File(dir, f); scanSingle(file, f, visitor);    
            pierrebtz Pierre Beitz made changes -
            Summary tar function is now breaking symlinks tar function is breaking symlinks
            pierrebtz Pierre Beitz made changes -
            Assignee Pierre Beitz [ pierrebtz ]
            Hide
            dnusbaum Devin Nusbaum added a comment -

            Pierre Beitz So if I understand correctly, the problem is that Archiver#visitSymlink does not even get called for symlinks when their target is a directory? If so, then something along the lines of what you proposed seems like the best approach. Do you know when the problem was first introduced?

            Show
            dnusbaum Devin Nusbaum added a comment - Pierre Beitz So if I understand correctly, the problem is that Archiver#visitSymlink does not even get called for symlinks when their target is a directory? If so, then something along the lines of what you proposed seems like the best approach. Do you know when the problem was first introduced?
            pierrebtz Pierre Beitz made changes -
            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.

             
            Hide
            pierrebtz Pierre Beitz added a comment -

            Devin Nusbaum: I just issued a PR, attaching it to this issue (I though there was a bot doing that for me, but it seems I was wrong).

            Show
            pierrebtz Pierre Beitz added a comment - Devin Nusbaum : I just issued a PR, attaching it to this issue (I though there was a bot doing that for me, but it seems I was wrong).
            pierrebtz Pierre Beitz made changes -
            Remote Link This issue links to "PR#3569 (Web Link)" [ 21250 ]
            pierrebtz Pierre Beitz made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            pierrebtz Pierre Beitz made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            abayer Andrew Bayer made changes -
            Link This issue is duplicated by JENKINS-54998 [ JENKINS-54998 ]
            abayer Andrew Bayer made changes -
            Link This issue is duplicated by JENKINS-55560 [ JENKINS-55560 ]
            Hide
            brianjmurrell Brian J Murrell added a comment -

            This seems to have been In Review for for 5 months now.  Is it really in review or is it stalled for some reason?  Where is the PR?

            Show
            brianjmurrell Brian J Murrell added a comment - This seems to have been In Review for for 5 months now.  Is it really in review or is it stalled for some reason?  Where is the PR?
            Hide
            pierrebtz Pierre Beitz added a comment -

            Brian J Murrell Review is stalled, the changes are a bit touchy and would need to be reviewed/discussed with more people. PR is linked to the ticket: https://github.com/jenkinsci/jenkins/pull/3569

            Show
            pierrebtz Pierre Beitz added a comment - Brian J Murrell Review is stalled, the changes are a bit touchy and would need to be reviewed/discussed with more people. PR is linked to the ticket:  https://github.com/jenkinsci/jenkins/pull/3569
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-37862 [ JENKINS-37862 ]
            Hide
            pierrebtz Pierre Beitz added a comment -

            As discussed in the associated PR this work will be superseded by https://issues.jenkins-ci.org/browse/JENKINS-37862.

            Show
            pierrebtz Pierre Beitz added a comment - As discussed in the associated PR  this work will be superseded by  https://issues.jenkins-ci.org/browse/JENKINS-37862 .
            pierrebtz Pierre Beitz made changes -
            Resolution Won't Fix [ 2 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            jglick Jesse Glick added a comment -

            Pierre Beitz the Shelve plugin could probably work around this issue by excluding known symlink filenames from its patternset.

            Show
            jglick Jesse Glick added a comment - Pierre Beitz the Shelve plugin could probably work around this issue by excluding known symlink filenames from its patternset.
            jglick Jesse Glick made changes -
            Resolution Won't Fix [ 2 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            jglick Jesse Glick made changes -
            Component/s shelve-project-plugin [ 15678 ]
            Component/s core [ 15593 ]
            jglick Jesse Glick made changes -
            Link This issue is duplicated by JENKINS-55560 [ JENKINS-55560 ]
            pierrebtz Pierre Beitz made changes -
            Status Reopened [ 4 ] Open [ 1 ]
            pierrebtz Pierre Beitz made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            pierrebtz Pierre Beitz made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            pierrebtz Pierre Beitz made changes -
            Remote Link This issue links to "PR#19 (Web Link)" [ 23112 ]
            Hide
            pierrebtz Pierre Beitz added a comment -
            Show
            pierrebtz Pierre Beitz added a comment - Jesse Glick you're right. Added this in the plugin:  https://github.com/jenkinsci/shelve-project-plugin/pull/19
            pierrebtz Pierre Beitz made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Fixed but Unreleased [ 10203 ]
            pierrebtz Pierre Beitz made changes -
            Status Fixed but Unreleased [ 10203 ] Resolved [ 5 ]
            pierrebtz Pierre Beitz made changes -
            Labels regression 2.5-fixed regression
            pierrebtz Pierre Beitz made changes -
            Labels 2.5-fixed regression 2.5-fixed

              People

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

                Dates

                Created:
                Updated:
                Resolved: