|
||||||||
|
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.
It seems that kohsuke’s f8014d974c6eb9f30098851bd7eeeec1edd1928f was overly optimistic; while in Java 7 Path.toRealPath correctly follows Windows symlinks, File.getCanonicalFile does not. That means that it is normal on Windows when using Java 6 for existing build records using symlinks (e.g. created when Jenkins was running on Java 7?) to display this error. The questions are
1. Why this is seen as a fatal error. Code up the call stack should catch the exception, print it, and ignore it, continuing the load the actual build directories.
2. How Jenkins running on Windows on Java 6 can safely ignore links. Maybe it should just quietly ignore anything named lastSomething or a number, without trying to determine if it is a link or not; and only report one-line warnings for directory entries with other (unexpected) names.