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

Symlink problem when moving Pipeline projects into folder

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • core
    • Jenkins ver. 2.8 running on Ubuntu 14.04
      Jenkins ver. 2.138.3 running on Windows Server 2016 Datacenter

      Trying out folder in jenkins 2.x, on moving a project (a pipline project to be specific) with no previous failure/instabilty, encountered a stack trace. The project did move, but none of the history made it.

      Perhaps lastUnstableBuild link doesn't exist for project with no prior unstable runs?

      Edit: tried the same with a freestyle project, that moved okey. Looks like it's likely specific to pipeline project.

      Stack trace
      
      java.io.FileNotFoundException: /local/mnt/workspace/jenkins/build_record/pipeline-test/lastUnstableBuild (No such file or directory)
      	at java.io.FileInputStream.open(Native Method)
      	at java.io.FileInputStream.<init>(FileInputStream.java:146)
      	at org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1138)
      	at org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1428)
      	at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1389)
      	at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1261)
      	at org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:1230)
      	at org.apache.commons.io.FileUtils.moveDirectory(FileUtils.java:2755)
      	at hudson.model.Job.movedTo(Job.java:683)
      	at hudson.model.Items.move(Items.java:438)
      	at com.cloudbees.hudson.plugins.folder.relocate.StandardHandler.doMove(StandardHandler.java:73)
      	at com.cloudbees.hudson.plugins.folder.relocate.StandardHandler.handle(StandardHandler.java:65)
      	at com.cloudbees.hudson.plugins.folder.relocate.DefaultRelocationUI.doMove(DefaultRelocationUI.java:121)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:324)
      	at org.kohsuke.stapler.interceptor.RequirePOST$Processor.invoke(RequirePOST.java:52)
      	at org.kohsuke.stapler.PreInvokeInterceptedFunction.invoke(PreInvokeInterceptedFunction.java:26)
      	at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:167)
      	at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:100)
      	at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:124)
      	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
      	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
      	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
      	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:813)
      	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
      	at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380)
      	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
      	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
      	at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:233)
      	at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
      	at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746)
      	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876)
      	at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
      	at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
      	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
      	at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
      	at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135)
      	at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95)
      	at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132)
      	at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59)
      	at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132)
      	at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:126)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:49)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
      	at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
      	at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
      	at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
      	at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
      	at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
      	at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
      	at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
      	at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:553)
      	at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
      	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
      	at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
      	at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
      	at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
      	at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
      	at org.eclipse.jetty.server.Server.handle(Server.java:499)
      	at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
      	at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
      	at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
      	at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
      	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
      	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:745)
      

          [JENKINS-35447] Symlink problem when moving Pipeline projects into folder

          Jesse Glick added a comment -

          Any known way to reproduce from scratch?

          Jesse Glick added a comment - Any known way to reproduce from scratch?

          I'm running into a similar issue on Windows. I can confirm that no build of the job ever had the result "UNSTABLE". But the job "builds" directory contains a "lastUnstableBuild" entry.

          ...
          09/08/2016  11:03 PM    <SYMLINKD>     lastFailedBuild [381]
          01/10/2017  05:26 PM    <SYMLINKD>     lastStableBuild [385]
          01/10/2017  05:26 PM    <SYMLINKD>     lastSuccessfulBuild [385]
          02/27/2015  09:26 AM    <SYMLINK>      lastUnstableBuild [-1]
          01/09/2017  03:50 PM    <SYMLINKD>     lastUnsuccessfulBuild [383]
          

          The job was only partly moved to the folder location. The job folder and build folder exists, but config.xml etc. is missing. The job is not shown in the folders-plugin folder.

          Trying to move the original job again results in

          org.apache.commons.io.FileExistsException: Destination 'D:\Jenkins\jobs\TestWorkflow\jobs\trunk\jobs\TestWorkflow_trunk_Production' already exists
          

          It seems to be save to delete the partially copied job from the folder (using a file manager) as it is only a copy so far. The original job seems to be unchanged.

          To reproduce the issue create a new (FreeStyle) job. This creates a builds directory inside the job directory with "last*" links. These are all pointing to "-1" (Windows Server 2012, NTFS file system)

           Directory of d:\Jenkins\jobs\FolderTest\builds
          
          03/01/2017  11:12 AM    <DIR>          .
          03/01/2017  11:12 AM    <DIR>          ..
          03/01/2017  11:12 AM    <SYMLINK>      lastFailedBuild [-1]
          03/01/2017  11:12 AM    <SYMLINK>      lastStableBuild [-1]
          03/01/2017  11:12 AM    <SYMLINK>      lastSuccessfulBuild [-1]
          03/01/2017  11:12 AM    <SYMLINK>      lastUnstableBuild [-1]
          03/01/2017  11:12 AM    <SYMLINK>      lastUnsuccessfulBuild [-1]
          03/01/2017  11:12 AM                 0 legacyIds
                         6 File(s)              0 bytes
          

          Trying to move this job will result in

          java.io.FileNotFoundException: D:\Jenkins\jobs\FolderTest\builds\lastFailedBuild (The system cannot find the file specified)
          

          Christoph Vogtländer added a comment - I'm running into a similar issue on Windows. I can confirm that no build of the job ever had the result "UNSTABLE". But the job "builds" directory contains a "lastUnstableBuild" entry. ... 09/08/2016 11:03 PM <SYMLINKD> lastFailedBuild [381] 01/10/2017 05:26 PM <SYMLINKD> lastStableBuild [385] 01/10/2017 05:26 PM <SYMLINKD> lastSuccessfulBuild [385] 02/27/2015 09:26 AM <SYMLINK> lastUnstableBuild [-1] 01/09/2017 03:50 PM <SYMLINKD> lastUnsuccessfulBuild [383] The job was only partly moved to the folder location. The job folder and build folder exists, but config.xml etc. is missing. The job is not shown in the folders-plugin folder. Trying to move the original job again results in org.apache.commons.io.FileExistsException: Destination 'D:\Jenkins\jobs\TestWorkflow\jobs\trunk\jobs\TestWorkflow_trunk_Production' already exists It seems to be save to delete the partially copied job from the folder (using a file manager) as it is only a copy so far. The original job seems to be unchanged. To reproduce the issue create a new (FreeStyle) job. This creates a builds directory inside the job directory with "last*" links. These are all pointing to "-1" (Windows Server 2012, NTFS file system) Directory of d:\Jenkins\jobs\FolderTest\builds 03/01/2017 11:12 AM <DIR> . 03/01/2017 11:12 AM <DIR> .. 03/01/2017 11:12 AM <SYMLINK> lastFailedBuild [-1] 03/01/2017 11:12 AM <SYMLINK> lastStableBuild [-1] 03/01/2017 11:12 AM <SYMLINK> lastSuccessfulBuild [-1] 03/01/2017 11:12 AM <SYMLINK> lastUnstableBuild [-1] 03/01/2017 11:12 AM <SYMLINK> lastUnsuccessfulBuild [-1] 03/01/2017 11:12 AM 0 legacyIds 6 File(s) 0 bytes Trying to move this job will result in java.io.FileNotFoundException: D:\Jenkins\jobs\FolderTest\builds\lastFailedBuild (The system cannot find the file specified)

          ilya rosman added a comment - - edited

          I can add some details.
          I found the same issue and googled this bug looking for
          java.io.FileNotFoundException: lastUnstableBuild (No such file or directory)
          First of all this issue is reproducible for the latest 5.18 folder_plugin version

          The root of this issue is the following.
          Let's assume we have the following job structure:

          ubuntu@ubuntu-xenial:~$ ls -l /var/lib/jenkins/jobs/XXX/builds/
          total 40
          drwxr-xr-x 2 1002 1002 4096 Feb 14 09:55 327
          drwxr-xr-x 4 1002 1002 4096 Feb 14 10:14 328
          drwxr-xr-x 4 1002 1002 4096 Feb 15 10:57 329
          drwxr-xr-x 4 1002 1002 4096 Feb 17 08:29 330
          drwxr-xr-x 4 1002 1002 4096 Feb 17 09:18 331
          drwxr-xr-x 4 1002 1002 4096 Feb 20 13:55 332
          drwxr-xr-x 4 1002 1002 4096 Feb 22 15:29 333
          drwxr-xr-x 4 1002 1002 4096 Feb 27 11:18 334
          lrwxrwxrwx 1 1002 1002    3 Feb 14 09:55 lastFailedBuild -> 327
          lrwxrwxrwx 1 1002 1002    3 Feb 27 11:18 lastStableBuild -> 334
          lrwxrwxrwx 1 1002 1002    3 Feb 27 11:18 lastSuccessfulBuild -> 334
          lrwxrwxrwx 1 1002 1002    2 Jun 27  2016 lastUnstableBuild -> -1
          lrwxrwxrwx 1 1002 1002    3 Feb 14 09:55 lastUnsuccessfulBuild -> 327
          -rw-r--r-- 1 1002 1002    0 Jun 27  2016 legacyIds
          

          Corresponding links point to existing folders excepting lastUnstableBuild which points to non existing dir for now.
          It is supposed to be changed when UnstableBuild appears. For example in 332 build version

          We wanna move XXX job to some newly created Test_Folder
          I used 3 cases how to handle it:
          1) Using Jenkins GUI
          2) Using post request
          curl -L -X POST http://10.229.55.117:8080/job/XXX/move/move?destination=/Test_Folder --user xxx:yyy
          3) Using groovy script like that

          def FOLDER_NAME = 'Test_Folder'
          def JOB_REGEX = 'XXX'
          import jenkins.*
          import jenkins.model.*
          import hudson.*
          import hudson.model.*
          jenkins = Jenkins.instance
          def folder = jenkins.getItemByFullName(FOLDER_NAME)
          if (folder == null) {
            println "ERROR: Folder '$FOLDER_NAME' not found"
            return
          }
          jenkins.items.grep { it.name =~ "${JOB_REGEX}" }.each { job ->
            println "Moving '$job.name' to '$folder.name'"
            Items.move(job, folder)
          }
          

          All these methods transform links (lastFailedBuild, lastStableBuild, lastSuccessfulBuild, lastUnsuccessfulBuild) to dirs (according to the content of 327, 334, 334, 327 correspondingly).
          In case of lastUnstableBuild -> -1 (points to nothing) it can not be transformed to dir and it is failed.

          As result moving is broken. Job is partially copied. Original is not deleted. It is why it can not be copied again (already exist) Copied version has dirs instead of links. lastUnstableBuild is missed.

          ubuntu@ubuntu-xenial:~$ ls -l /var/lib/jenkins/jobs/Test_Folder/jobs/XXX/builds/
          total 56
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 13 12:17 325
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 14 09:16 326
          drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 327
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 14 10:14 328
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 15 10:57 329
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 17 08:29 330
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 17 09:18 331
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 20 13:55 332
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 15:29 333
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 334
          drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 lastFailedBuild
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 lastStableBuild
          drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 lastSuccessfulBuild
          drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 lastUnsuccessfulBuild
          -rw-r--r-- 1 jenkins jenkins    0 Jun 27  2016 legacyIds
          

          P.s. As we can see, the only 1 safest way for us (to migrate jobs to folders) is using cp -arp copying on jenkins linux master from jobs folder to Name_of_Folder/jobs. Then jenkins reloading/restarting

          ilya rosman added a comment - - edited I can add some details. I found the same issue and googled this bug looking for java.io.FileNotFoundException: lastUnstableBuild (No such file or directory) First of all this issue is reproducible for the latest 5.18 folder_plugin version The root of this issue is the following. Let's assume we have the following job structure: ubuntu@ubuntu-xenial:~$ ls -l / var /lib/jenkins/jobs/XXX/builds/ total 40 drwxr-xr-x 2 1002 1002 4096 Feb 14 09:55 327 drwxr-xr-x 4 1002 1002 4096 Feb 14 10:14 328 drwxr-xr-x 4 1002 1002 4096 Feb 15 10:57 329 drwxr-xr-x 4 1002 1002 4096 Feb 17 08:29 330 drwxr-xr-x 4 1002 1002 4096 Feb 17 09:18 331 drwxr-xr-x 4 1002 1002 4096 Feb 20 13:55 332 drwxr-xr-x 4 1002 1002 4096 Feb 22 15:29 333 drwxr-xr-x 4 1002 1002 4096 Feb 27 11:18 334 lrwxrwxrwx 1 1002 1002 3 Feb 14 09:55 lastFailedBuild -> 327 lrwxrwxrwx 1 1002 1002 3 Feb 27 11:18 lastStableBuild -> 334 lrwxrwxrwx 1 1002 1002 3 Feb 27 11:18 lastSuccessfulBuild -> 334 lrwxrwxrwx 1 1002 1002 2 Jun 27 2016 lastUnstableBuild -> -1 lrwxrwxrwx 1 1002 1002 3 Feb 14 09:55 lastUnsuccessfulBuild -> 327 -rw-r--r-- 1 1002 1002 0 Jun 27 2016 legacyIds Corresponding links point to existing folders excepting lastUnstableBuild which points to non existing dir for now. It is supposed to be changed when UnstableBuild appears. For example in 332 build version We wanna move XXX job to some newly created Test_Folder I used 3 cases how to handle it: 1) Using Jenkins GUI 2) Using post request curl -L -X POST http://10.229.55.117:8080/job/XXX/move/move?destination=/Test_Folder --user xxx:yyy 3) Using groovy script like that def FOLDER_NAME = 'Test_Folder' def JOB_REGEX = 'XXX' import jenkins.* import jenkins.model.* import hudson.* import hudson.model.* jenkins = Jenkins.instance def folder = jenkins.getItemByFullName(FOLDER_NAME) if (folder == null ) { println "ERROR: Folder '$FOLDER_NAME' not found" return } jenkins.items.grep { it.name =~ "${JOB_REGEX}" }.each { job -> println "Moving '$job.name' to '$folder.name' " Items.move(job, folder) } All these methods transform links (lastFailedBuild, lastStableBuild, lastSuccessfulBuild, lastUnsuccessfulBuild) to dirs (according to the content of 327, 334, 334, 327 correspondingly). In case of lastUnstableBuild -> -1 (points to nothing) it can not be transformed to dir and it is failed. As result moving is broken. Job is partially copied. Original is not deleted. It is why it can not be copied again (already exist) Copied version has dirs instead of links. lastUnstableBuild is missed. ubuntu@ubuntu-xenial:~$ ls -l / var /lib/jenkins/jobs/Test_Folder/jobs/XXX/builds/ total 56 drwxr-xr-x 4 jenkins jenkins 4096 Feb 13 12:17 325 drwxr-xr-x 4 jenkins jenkins 4096 Feb 14 09:16 326 drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 327 drwxr-xr-x 4 jenkins jenkins 4096 Feb 14 10:14 328 drwxr-xr-x 4 jenkins jenkins 4096 Feb 15 10:57 329 drwxr-xr-x 4 jenkins jenkins 4096 Feb 17 08:29 330 drwxr-xr-x 4 jenkins jenkins 4096 Feb 17 09:18 331 drwxr-xr-x 4 jenkins jenkins 4096 Feb 20 13:55 332 drwxr-xr-x 4 jenkins jenkins 4096 Feb 22 15:29 333 drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 334 drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 lastFailedBuild drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 lastStableBuild drwxr-xr-x 4 jenkins jenkins 4096 Feb 27 11:18 lastSuccessfulBuild drwxr-xr-x 2 jenkins jenkins 4096 Feb 14 09:55 lastUnsuccessfulBuild -rw-r--r-- 1 jenkins jenkins 0 Jun 27 2016 legacyIds P.s. As we can see, the only 1 safest way for us (to migrate jobs to folders) is using cp -arp copying on jenkins linux master from jobs folder to Name_of_Folder/jobs. Then jenkins reloading/restarting

          Jesse Glick added a comment -

          Probably a dupe of one of the many issues requesting that we cease to use symlinks for build numbers. schristou what happened to your patch?

          Jesse Glick added a comment - Probably a dupe of one of the many issues requesting that we cease to use symlinks for build numbers. schristou what happened to your patch?

          ilya rosman added a comment -

          Some addition from my side.
          First of all I want to apologize for not finding that before.
          I just understood that the root of wrong behavior during links copying is invalid ownership
          U can see it from my previous comment. Historically job (which I'm trying to move) was migrated from some another server. And during migration (archiving, copying, unpacking) ownership was lost (1002 1002 instead of jenkins jenkins)
          I fixed that in my filesystem and everything is fine for now.

          sudo chown -R jenkins:jenkins jobs/XXX
          

          So I even do not know is it a bug or not. Should system check/repair ownership...

          ilya rosman added a comment - Some addition from my side. First of all I want to apologize for not finding that before. I just understood that the root of wrong behavior during links copying is invalid ownership U can see it from my previous comment. Historically job (which I'm trying to move) was migrated from some another server. And during migration (archiving, copying, unpacking) ownership was lost (1002 1002 instead of jenkins jenkins) I fixed that in my filesystem and everything is fine for now. sudo chown -R jenkins:jenkins jobs/XXX So I even do not know is it a bug or not. Should system check/repair ownership...

          Andrew Gray added a comment -

          This issue is also occurring on Windows.

          Andrew Gray added a comment - This issue is also occurring on Windows.

          Andrew Gray added a comment -

          Is there a plan to fix this for both Linux and Windows?

          Andrew Gray added a comment - Is there a plan to fix this for both Linux and Windows?

          Jesse Glick added a comment -

          Probably obsolete as of JENKINS-37862. (No new build symlinks are created or updated. See the upgrade guide; existing symlinks are not removed automatically.)

          Jesse Glick added a comment - Probably obsolete as of JENKINS-37862 . (No new build symlinks are created or updated. See the upgrade guide; existing symlinks are not removed automatically.)

            Unassigned Unassigned
            hangdong Hang Dong
            Votes:
            4 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: