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

FilePath's copyRecursiveTo doesn't handle Chinese characters

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • core
    • None
    • windows server 2008,+jenkins + html publish plugin 1.2 statsvn0.7

      HTML Publisher for example uses copyRecursiveTo as such: copyRecursiveTo("*/", targetDir) (https://github.com/jenkinsci/htmlpublisher-plugin/blob/master/src/main/java/htmlpublisher/HtmlPublisher.java#L212), and in the attached screenshot one can see that it can fail if the glob matches certain characters.

          [JENKINS-18558] FilePath's copyRecursiveTo doesn't handle Chinese characters

          mcrooney added a comment -

          Thanks for the report. I think this might be a bug in core so I've updated the description to match the use of the copyRecursiveTo function and see if that is the problem. If anyone knows of something different, such as that the HTML Plugin should be using copyRecursiveTo in a different way, certainly let me know, but otherwise it appears to be a core bug.

          mcrooney added a comment - Thanks for the report. I think this might be a bug in core so I've updated the description to match the use of the copyRecursiveTo function and see if that is the problem. If anyone knows of something different, such as that the HTML Plugin should be using copyRecursiveTo in a different way, certainly let me know, but otherwise it appears to be a core bug.

          When I read relevant part of the core source code, I think it handles the situation correctly where the encoding of the master and the slave are different.

          During a recursive copy, files are packed into a tar format with what's known as "GNU-style long file name" extension, which stores file names in UTF-8. The master reads them back as such and then tries to create files of the same name.

          I suspect the master JVM's default encoding is set to iso-8859-1 or something that cannot map some non-ASCII characters. I recommend you check the LANG environment variable on the master JVM.

          Kohsuke Kawaguchi added a comment - When I read relevant part of the core source code, I think it handles the situation correctly where the encoding of the master and the slave are different. During a recursive copy, files are packed into a tar format with what's known as "GNU-style long file name" extension, which stores file names in UTF-8. The master reads them back as such and then tries to create files of the same name. I suspect the master JVM's default encoding is set to iso-8859-1 or something that cannot map some non-ASCII characters. I recommend you check the LANG environment variable on the master JVM.

          ying zhang added a comment -

          "Kohsuke Kawaguchi added a comment - 02/Jul/13 3:41 PM
          ……
          I suspect the master JVM's default encoding is set to iso-8859-1 or something that cannot map some non-ASCII characters. I recommend you check the LANG environment variable on the master JVM."

          I just find that the default encoding of Windows system is utf16le ,and cannot be changed, so I try to use another Linux system to create the statsvn report. ╮(╯▽╰)╭

          ying zhang added a comment - "Kohsuke Kawaguchi added a comment - 02/Jul/13 3:41 PM …… I suspect the master JVM's default encoding is set to iso-8859-1 or something that cannot map some non-ASCII characters. I recommend you check the LANG environment variable on the master JVM." I just find that the default encoding of Windows system is utf16le ,and cannot be changed, so I try to use another Linux system to create the statsvn report. ╮(╯▽╰)╭

            kohsuke Kohsuke Kawaguchi
            rexuekonglong ying zhang
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: