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 created issue -

          Alan Harder added a comment -

          started

          Alan Harder added a comment - started
          Alan Harder made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Alan Harder added a comment -

          r21046 | mindless | 2009-08-24 15:36:34 -0600 (Mon, 24 Aug 2009) | 2 lines
          Changed paths:
          M /trunk/hudson/main/core/src/main/java/hudson/Util.java
          M /trunk/www/changelog.html

          [FIXED JENKINS-4301] Creation of symlinks failed (or created in wrong location)
          since 1.320.

          Alan Harder added a comment - r21046 | mindless | 2009-08-24 15:36:34 -0600 (Mon, 24 Aug 2009) | 2 lines Changed paths: M /trunk/hudson/main/core/src/main/java/hudson/Util.java M /trunk/www/changelog.html [FIXED JENKINS-4301] Creation of symlinks failed (or created in wrong location) since 1.320.
          Alan Harder made changes -
          Resolution New: Fixed [ 1 ]
          Status Original: In Progress [ 3 ] New: Resolved [ 5 ]

          kcbaltz added a comment -

          I'm not sure this is fixed all the way. We're having trouble with symlinks not
          being created. Taking a look at the source, it appears that when the PosixAPI
          is used to create symlinks, they don't have any kind of basedir prepended. E.g.
          I think this:

          r = PosixAPI.get().symlink(targetPath,symlinkFile.getAbsolutePath());

          doesn't work because targetPath="2009-10-05_14-13-08" when I ran it in debug
          mode. I think it should have a path prepended to that build ID.

          I was able to use the SYMLINK_ESCAPEHATCH variable to work around this problem.
          For others reading this, that meant adding the following to the command line:

          -Dhudson.Util.symlinkEscapeHatch=true

          kcbaltz added a comment - I'm not sure this is fixed all the way. We're having trouble with symlinks not being created. Taking a look at the source, it appears that when the PosixAPI is used to create symlinks, they don't have any kind of basedir prepended. E.g. I think this: r = PosixAPI.get().symlink(targetPath,symlinkFile.getAbsolutePath()); doesn't work because targetPath="2009-10-05_14-13-08" when I ran it in debug mode. I think it should have a path prepended to that build ID. I was able to use the SYMLINK_ESCAPEHATCH variable to work around this problem. For others reading this, that meant adding the following to the command line: -Dhudson.Util.symlinkEscapeHatch=true
          kcbaltz made changes -
          Resolution Original: Fixed [ 1 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          kcbaltz added a comment -

          Adding myself to cc list

          kcbaltz added a comment - Adding myself to cc list

          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".

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

              Created:
              Updated:
              Resolved: