[JIRA] (JENKINS-15331) Workaround Windows unpredictable file locking in Util.deleteContentsRecursive

[pjdar...@java.net (JIRA)]

pjdarton commented on JENKINS-15331 Workaround Windows unpredictable file locking in Util.deleteContentsRecursive Added pull request https://github.com/jenkinsci/jenkins/pull/583 Features: Added two new system properties that control behavior: "Util.deletionRetries" (an integer, defaults to 3) and "Util.deletionRetryWait" (an integer, defaults to 500ms). Delete operations that affect directories now try to delete the entire contents of the directory, continuing on to subfolders etc even after encountering files that wouldn't die, before eventually throwing an exception about what wouldn't die. i.e. if a folder has a file "a", "b" and "c", and you can't delete "b", then "a" and "c" would get deleted (and you'll still get the exception about "b"). Delete operations now have multiple attempts at deleting things, so if not everything could be deleted first time around, maybe they'll get deleted 2nd/3rd etc time around. An exception is only thrown if all retry attempts are exhausted and there are still files/directories that won't delete. I have high hopes that this will mean that I will no longer suffer from JENKINS-15331 (possibly with a higher retry count, as Windows can take a dozen attempts to delete a file sometimes - I've set the defaults to mimic existing behavior). Disclaimers: It's undergone very little testing. Building the master branch failed consistently on my PC at the time, but it continued to fail in exactly the same way once I'd done my changes. It's entirely possible that the changes will fail to fix the problem as I've been unable to build & run Jenkins from this code. To compensate, I have added some additional unit-tests that give me confidence that, at the very least, the changes should do no harm. Although the GitHub Windows client is very pretty, it looks like it has also asked the GitHub server to change all the end-of-line codes in a manner that makes GitHub think I've changed the entire file, which isn't true - when pressed the publish button on my PC, it wasn't changing the entire file, it only looked like that immediately afterwards. As a result, it may be necessary to change the EOLs back again. (One day, I'll get the hang of using git from a Windows machine, but today was not that day...) If further testing is required, I'd be happy to accept a built Jenkins (that included my changes) to test. Normally I'd do that before issuing a "pull request", but as it doesn't seem to want to build at all on my PC here, I don't really have that option (if there are other ways of getting a Jenkins built, e.g. by getting another server to do the build from my GitHub repo, do let me know by email at pet...@intrinsica.co.uk).

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