Also, after running it and getting "jobname #40285 is to be removed", is the build still there in Jenkins? On the disk?

stack trace came from Jenkins script console while running: Jenkins.instance.getItemByFullName('xyz').logRotate()

yes, directory for #40285 is still on HDD. It can still be access via file system or Jenkins UI. Compared with legit build directories it starts with a . and is named as follows: .2014-05-19_08-41-18
2013-12-11_10-01-34 << build directory which isn't visible in UI
2014-05-19_16-41-19 << locked

In the regular Jenkins log, there should be an error related to failing to delete files. The '.' gets added when Jenkins removes a build.

2013-12-11_10-01-34 << build directory which isn't visible in UI

Is there a config.xml file in the directory?

What happens to both of these builds when you reload configuration from disk?

1) reloading from disk removed at least #40285 from the Jenkins UI. Why wouldn't it go away by itself without reloading the job configs?

2) 2013-12-11_10-01-34 contains: changelog.xml, log file and timestamper directory which contains timestamps file

3) when will those empty build directories being deleted from HDD which start with . as this job already has 13 of them?

1) reloading from disk removed at least #40285 from the Jenkins UI. Why wouldn't it go away by itself without reloading the job configs?

My guess is that the build deletion got interrupted by some Windows process (e.g. your antivirus or search indexer) locking a file. Hence the build was still in memory, but no longer (in the expected location) on disk, so it could not be loaded again.

2) 2013-12-11_10-01-34 contains: changelog.xml, log file and timestamper directory which contains timestamps file

No build.xml file, so it cannot be loaded. You should see a warning logged about this on Jenkins startup.

3) when will those empty build directories being deleted from HDD which start with . as this job already has 13 of them?

To the best of my knowledge, when you delete them manually. Their existence means the deletion of a build failed.

That a failure to delete the dot-build directory causes Jenkins to keep the build in memory seems weird. Should probably be filed as a bug if it's not already.

@robsimon: those diagnostics were added for JENKINS-22395, though it is not clear there is any relationship.

Hi,
This issue was created in feb, 2013.
I have commented in feb, 2014.
And now about 10 updates from 3 people in 1 week, just for one issue.
What is going on?

sorry for getting side-tracked while going thru this issue here.

i guess this issue can be closed as the original problem of "keep forever builds get removed" does not occur any more with a newer Jenkins version.

evernat: I'm currently going through older issues, closing or poking as appropriate (as I'm sure you've seen, given the number of issues I'm resolving after nobody responded to your comments!). Since I knew Jesse investigated a similar issue as mentioned in a comment ("looks to have already been deleted") I pointed this issue out to him. And finally, the Jira mailer is a bit unreliable, so it's possible your comment wasn't seen by anyone before I posted mine (see robsimon's first comment).

robsimon: I already resolved this as 'Incomplete' after there was no response to evernat's comment – while it seems to be more of a 'Cannot Reproduce', it doesn't really matter. (And we're not consistently closing issues in this Jira AFAICT).

Sorry, false alarm