|
||||||||||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
This is not a bug in Jenkins but a misconfigured LANG header.
POSIX treats file names as a sequence of bytes, and Java treats them as a sequence of chars. Thus a certain encoding needs to be asumed, and in Java that is governed by the LANG header.
What Jenkins is doing when it's in Util.deleteRecursive is that it's listing all the files in a directory (bytes->chars conv), then delete them one by one (chars->bytes conv.) If the LANG header is such that this file name converstion process isn't loseless (for example, the file is created from LANG=en_US.UTF-8 process but read as LANG=en_US.iso-8859-1), then you see the problem you are seeing.
Check the system information of the slave process in question to make sure that it's having the right encoding set in the LANG environment variable. If not, check the way you are launching the process and check where in your slave the LANG header is supposed to be set.
Note that abayer is wrong about the role of the file.encoding system property. This is about how Java process reads the contents of files, and it has nothing to do with the encoding of file names.