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

Hudson follows symlinks when deleting

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: other
    • Labels:
      None
    • Environment:
      Platform: All, OS: Linux
    • Similar Issues:

      Description

      In our build system, we make a symlink from the build tree to the system
      configuration. When removing a project from Hudson, it all got deleted!

      To reproduce:

      Create a new job "Test".

      $ ln -s ~/precious ~/.hudson/jobs/Test/builds/link-to-precious
      $ ls ~/precious
      my-data

      Delete Project "Test" using the web interface.

      $ ls ~/precious

      My data is gone!

        Attachments

          Issue Links

            Activity

            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            See similar problem at
            http://david.olrik.dk/articles/2006/02/01/ant-does-not-respect-symlinks

            Java doesn't let us check if a directory is a symlink, nor does it support a
            recursive deletion library call, so this is rather hard to do correctly.

            I'm planning to try somewhere along the line of this:
            http://joust.kano.net/weblog/archives/000071.html

            Show
            kohsuke Kohsuke Kawaguchi added a comment - See similar problem at http://david.olrik.dk/articles/2006/02/01/ant-does-not-respect-symlinks Java doesn't let us check if a directory is a symlink, nor does it support a recursive deletion library call, so this is rather hard to do correctly. I'm planning to try somewhere along the line of this: http://joust.kano.net/weblog/archives/000071.html
            Hide
            jglick Jesse Glick added a comment -

            I don't think the code you referred to is correct. It may well be that the
            entire Hudson workspace is located inside a symlink. In such a case, you would
            wind up deleting nothing! What you want to check is whether a file inside a
            given folder is a symlink. I think you would need something like this:

            File parent = ...;
            String childName = ...;
            boolean symlink = !new File(parent,
            childName).getCanonicalPath().equals(parent.getCanonicalPath() +
            File.separatorChar + childName);

            I doubt the above is completely safe on all operating systems, either, but it
            might be the best you can do in the absence of JSR 203.

            Show
            jglick Jesse Glick added a comment - I don't think the code you referred to is correct. It may well be that the entire Hudson workspace is located inside a symlink. In such a case, you would wind up deleting nothing! What you want to check is whether a file inside a given folder is a symlink. I think you would need something like this: File parent = ...; String childName = ...; boolean symlink = !new File(parent, childName).getCanonicalPath().equals(parent.getCanonicalPath() + File.separatorChar + childName); I doubt the above is completely safe on all operating systems, either, but it might be the best you can do in the absence of JSR 203.
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Another note to myself: http://svn.apache.org/viewvc/maven/shared/tags/file-management-1.0/src/main/java/org/apache/maven/shared/model/fileset/util/FileSetManager.java?view=markup
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            I copied the code from Maven to implement this. Presumably it is well tested.

            The change is in 1.112.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - I copied the code from Maven to implement this. Presumably it is well tested. The change is in 1.112.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -
                • Issue 783 has been marked as a duplicate of this issue. ***
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Issue 783 has been marked as a duplicate of this issue. ***
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            This problem was still not properly fixed in 1.135.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - This problem was still not properly fixed in 1.135.
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Fixed properly in 1.136.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Fixed properly in 1.136.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              tal tal
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: