-
Bug
-
Resolution: Fixed
-
Major
The implementation of AtomicFileWriter is not actually atomic.
There are several issues with it.
- the rename first deletes the target giving a window of opportunity for no file to exist.
- the rename of the file will rename the file but the data in the file may not have been flushed to disk. In XFS this is a biggy as the metadata and filedata are written separatly - so despite the file being closed there is not fsync call - so if the system crashes you end up with zero length files.
This has been observed in the wild when the OS hosting jenkins crashed, on restart several of Jenkins files were zero length.
Jenkins should make use of java.nio to make sure
- data is actually synced
- it uses atomic operations for move on platforms where it is available.
- relates to
-
JENKINS-48407 Permission issue after upgrade to 2.93
- Resolved
-
JENKINS-36088 Use NIO rather than JNR whenever possible
- Resolved
-
JENKINS-47324 FilePath API in Jenkins should propagate errors
- Closed
- links to
(2 links to)