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

Creation of build symlinks fails ("ln failed")

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      r20948 introduced 2 problems:

      1) Old symlinks are no longer removed.. the "if exists" check that was added
      does not account for the baseDir, so it always thinks the symlink does not
      exist. Creation of the symlink then fails because of the conflict with existing
      link. (this applies to overwrite of "latestStable", "latestSuccessful" links, etc.)

      2) Creation of symlinks via PosixAPI does not work because it does not account
      for the baseDir.

          [JENKINS-4301] Creation of build symlinks fails ("ln failed")

          Alan Harder added a comment -

          The targetPath parameter does not need to be absolute.. at least, I don't know
          of any system where symlinks can't be relative.
          Example: ln -s somefile /tmp/testlink
          This creates /tmp/testlink as a symlink pointing to "somefile" in the same
          directory (so /tmp/somefile).

          The fix in this issue was making sure the 2nd param is an absolute path, so
          the symlink is created in the right location.
          If you have other clues as to why symlinks weren't created on your setup, please
          let us know.. can you share your environment details?

          Alan Harder added a comment - The targetPath parameter does not need to be absolute.. at least, I don't know of any system where symlinks can't be relative. Example: ln -s somefile /tmp/testlink This creates /tmp/testlink as a symlink pointing to "somefile" in the same directory (so /tmp/somefile). The fix in this issue was making sure the 2nd param is an absolute path, so the symlink is created in the right location. If you have other clues as to why symlinks weren't created on your setup, please let us know.. can you share your environment details?

          kcbaltz added a comment -

          I would agree that it's valid syntax to use relative directories. However, that
          depends on the current working directory being set correctly in order for it to
          work. As far as I could tell, the CWD was set to the directory where we have
          all our Hudson files, /data/hudson. 'jobs' is a sub-directory of this dir. I
          checked this by looking at System.getProperty("user.dir").

          As far as our environment goes, we are running Hudson standalone on Solaris 10.
          The error message we were getting was "ln failed: -1".

          kcbaltz added a comment - I would agree that it's valid syntax to use relative directories. However, that depends on the current working directory being set correctly in order for it to work. As far as I could tell, the CWD was set to the directory where we have all our Hudson files, /data/hudson. 'jobs' is a sub-directory of this dir. I checked this by looking at System.getProperty("user.dir"). As far as our environment goes, we are running Hudson standalone on Solaris 10. The error message we were getting was "ln failed: -1".

          Alan Harder added a comment -

          Again, you're describing the problem that was fixed in this issue. It is the
          2nd parameter that determines where the link is created.. if you use a relative
          path here (as it did before this issue was fixed) it will create the link
          relative to the CWD, which Hudson did from 1.320 to 1.322. The first parameter
          can be relative, and will be relative to where the link is, unrelated to the CWD
          at the time the link was created.
          What version of Hudson are you using?

          Alan Harder added a comment - Again, you're describing the problem that was fixed in this issue. It is the 2nd parameter that determines where the link is created.. if you use a relative path here (as it did before this issue was fixed) it will create the link relative to the CWD, which Hudson did from 1.320 to 1.322. The first parameter can be relative, and will be relative to where the link is, unrelated to the CWD at the time the link was created. What version of Hudson are you using?

          kcbaltz added a comment -

          We saw this problem with 1.325 and 1.327.

          Regarding the use of ln, I stand corrected. I hadn't realized that the target
          argument was relative to the source argument. Now I'm not sure why it's
          failing. I do know that switching to the SYMLINK_ESCAPEHATCH mode fixed the
          problem.

          kcbaltz added a comment - We saw this problem with 1.325 and 1.327. Regarding the use of ln, I stand corrected. I hadn't realized that the target argument was relative to the source argument. Now I'm not sure why it's failing. I do know that switching to the SYMLINK_ESCAPEHATCH mode fixed the problem.

          sbouchet added a comment -

          Hi,

          at eclipse.org, we ran into the same problem with version 1.328. you can follow
          the discussion here :

          https://bugs.eclipse.org/bugs/show_bug.cgi?id=292629#c20

          sbouchet added a comment - Hi, at eclipse.org, we ran into the same problem with version 1.328. you can follow the discussion here : https://bugs.eclipse.org/bugs/show_bug.cgi?id=292629#c20

          adding myself to cc list

          davidzzzwilliams added a comment - adding myself to cc list

          Alan Harder added a comment -

          can people seeing this problem please post your Hudson version, OS type/version,
          java version, webserver type/version? Thanks.

          Alan Harder added a comment - can people seeing this problem please post your Hudson version, OS type/version, java version, webserver type/version? Thanks.

          Alan Harder added a comment -

          kohsuke changed the createSymlink method to use GNUC library instead of POSIX..
          hopefully this will help. sbouchet, please test when Hudson 1.333 comes out and
          let us know if we can close this issue, thanks!

          r23471 | kohsuke | 2009-11-04 12:29:25 -0700 (Wed, 04 Nov 2009) | 1 line
          Changed paths:
          M /trunk/hudson/main/core/src/main/java/hudson/Util.java

          this is more portable.

          Alan Harder added a comment - kohsuke changed the createSymlink method to use GNUC library instead of POSIX.. hopefully this will help. sbouchet, please test when Hudson 1.333 comes out and let us know if we can close this issue, thanks! r23471 | kohsuke | 2009-11-04 12:29:25 -0700 (Wed, 04 Nov 2009) | 1 line Changed paths: M /trunk/hudson/main/core/src/main/java/hudson/Util.java this is more portable.

          Alan Harder added a comment -

          Looks like this caused issue #4820

          Alan Harder added a comment - Looks like this caused issue #4820

          Alan Harder added a comment -

          Closing this issue; please track issue #4820 for additional work on this.

          Alan Harder added a comment - Closing this issue; please track issue #4820 for additional work on this.

            mindless Alan Harder
            mindless Alan Harder
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: