• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • p4-plugin

      After updating from 1.10.0 to 1.10.3 I am seeing the following errors on Windows build slaves:

      15:00:01  ERROR: P4: Task Exception: com.perforce.p4java.exception.P4JavaException: com.perforce.p4java.exception.P4JavaException: hudson.AbortException: P4JAVA: Error(s):
      15:00:01  symlink file <some symlink> can't be sync'd or created with this client program.
      

      Note that we are using a virtual stream. 

       

          [JENKINS-59213] P4 Plugin - Errors when syncing symlinks

          Paul Allen added a comment -

          It's possible that the older 1.10.0 release may have left a 'bad' symlink in your workspace with strange permissions.  You may need to use 'administrator' permissions to clean up the file. 

          Windows has a few types of symlinks; the plugin only supports 'symlinks' not 'junctions' JENKINS-57955.

          If it still causes a problem please let me know.

          Paul Allen added a comment - It's possible that the older 1.10.0 release may have left a 'bad' symlink in your workspace with strange permissions.  You may need to use 'administrator' permissions to clean up the file.  Windows has a few types of symlinks; the plugin only supports 'symlinks' not 'junctions'  JENKINS-57955 . If it still causes a problem please let me know.

          Ivan Tashev added a comment - - edited

          Hey p4paul, thank you for the responce.

          The error was actually revealed after I did a full wipe and recreate of the workspace (after basically deleting local files and p4 client). I am not sure this is an OS specific issue, as I can sync the files on the same build node with P4V using the same p4 client. 

          Ivan Tashev added a comment - - edited Hey p4paul , thank you for the responce. The error was actually revealed after I did a full wipe and recreate of the workspace (after basically deleting local files and p4 client). I am not sure this is an OS specific issue, as I can sync the files on the same build node with P4V using the same p4 client. 

          Karl Wirth added a comment -

          Hi ivtashev - I'd like to ask you for some system specific information so is it OK if I email you directly?

           

          Karl Wirth added a comment - Hi ivtashev - I'd like to ask you for some system specific information so is it OK if I email you directly?  

          Paul Allen added a comment -

          Released in 1.10.6

          Paul Allen added a comment - Released in 1.10.6

          Kurt Routley added a comment -

          p4paul p4karl I work with ivtashev and we hit the issue again after upgrading to P4 Plugin 1.11.0 from 1.10.3, however after testing with multiple versions of p4 client and p4 plugin, discovered the issue was with the symlink file itself, which was 3.8MB (surprisingly large for a symlink file). We have worked around the issue by updating the view mapping to exclude that path (since the file in question was no longer required), but at this point I don't believe it is a regression issue, as other regular sized symlink files did not encounter sync failures.

          Environment details:

          Jenkins 2.249.1

          SSH Agent on Mac OS X 10.15.6

          Perforce server running P4D/LINUX26X86_64/2020.1/1991450 (2020/07/31)

          Tests:

           

          P4 Client Version P4 Plugin (+ p4java) Version Sync Type View Mapping Included Large Symlink Successful?
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.3 (2019.1.1827134) Incremental Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.3 (2019.1.1827134) New workspace Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.6 (2019.1.1873579) Incremental Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.6 (2019.1.1873579) New workspace Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.7 (2019.1.1889202) Incremental Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.7 (2019.1.1889202) New workspace Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.11.0 (2020.1.1999383) Incremental Yes No
          P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.11.0 (2020.1.1999383) New workspace Yes No
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) Incremental Yes No
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) New workspace Yes No
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) Incremental Yes No
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) New workspace Yes No
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) Incremental No Yes
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) New workspace No Yes
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) Incremental No Yes
          P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) New workspace No Yes

           

          Kurt Routley added a comment - p4paul p4karl I work with ivtashev and we hit the issue again after upgrading to P4 Plugin 1.11.0 from 1.10.3, however after testing with multiple versions of p4 client and p4 plugin, discovered the issue was with the symlink file itself, which was 3.8MB (surprisingly large for a symlink file). We have worked around the issue by updating the view mapping to exclude that path (since the file in question was no longer required), but at this point I don't believe it is a regression issue, as other regular sized symlink files did not encounter sync failures. Environment details: Jenkins 2.249.1 SSH Agent on Mac OS X 10.15.6 Perforce server running P4D/LINUX26X86_64/2020.1/1991450 (2020/07/31) Tests:   P4 Client Version P4 Plugin (+ p4java) Version Sync Type View Mapping Included Large Symlink Successful? P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.3 (2019.1.1827134) Incremental Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.3 (2019.1.1827134) New workspace Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.6 (2019.1.1873579) Incremental Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.6 (2019.1.1873579) New workspace Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.7 (2019.1.1889202) Incremental Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.10.7 (2019.1.1889202) New workspace Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.11.0 (2020.1.1999383) Incremental Yes No P4/MACOSX1010X86_64/2019.2/1897966 (2019/12/16) 1.11.0 (2020.1.1999383) New workspace Yes No P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) Incremental Yes No P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) New workspace Yes No P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) Incremental Yes No P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) New workspace Yes No P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) Incremental No Yes P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.10.3 (2019.1.1827134) New workspace No Yes P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) Incremental No Yes P4/MACOSX(1015X86_64/2020.1/2007551 (2020/09/08) 1.11.0 (2020.1.1999383) New workspace No Yes  

          Paul Allen added a comment -

          Typically symlinks are stored as RCS files where the 'text' section should just contain the filename.  When you say the symlink was 3.8MB was that the size on disk in the client workspace, the server's lbr file size or the size reported by 'p4 sizes'?

          It's possible the file has been corrupted or was previously a regular file and then changed into a symlink.

          If you do find an issue with the p4-plugin, please let support know and reopen this issue.

          Paul Allen added a comment - Typically symlinks are stored as RCS files where the 'text' section should just contain the filename.  When you say the symlink was 3.8MB was that the size on disk in the client workspace, the server's lbr file size or the size reported by 'p4 sizes'? It's possible the file has been corrupted or was previously a regular file and then changed into a symlink. If you do find an issue with the p4-plugin, please let support know and reopen this issue.

            cbopardikar Charusheela Bopardikar
            ivtashev Ivan Tashev
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: