In our case, these exceptions appear to relate to kaspersky antivirus running on the jenkins server. The underlying problem is that the antivirus file scans are integrated in windows in an asynchronous way (for performance/design reasons) Therefore, the scans can temporarily lock files or keep them alive for a short time after a delete operation appears to have succeeded.
For us the fingerprint exception above has become the most frequent cause for random build failures (p~1/200) and we are wondering if this code properly uses the retry infrastructure built elsewhere in jenkins. (
JENKINS-15331) (Turning kaspersky off temporarily helped but we do want to keep it running)
Looking at hudson.model.Fingerprint.save() it appears there is no retry implemented, but doing so on top of AtomicFileWriter.commit() sounds like potential trouble...