Possible race condition in copyFile
Implementation of copyFile
- Creates .copyFile.tmp at destination using openBinaryTempFile.
- Copies contents of the source file using copyContents.
- Renames the temporary file to source using renameFile.
Operations 2 and 3 are not atomic. If some program B expects file at the destination then the race evolves: B sees .copyFileXXX.tmp instead of the true file name and if B consumes file before rename then copyContens fails due to renameFile failure.
Implementation seems strange to me. Why not just use system API? This should also fix #5251 (closed)
Trac metadata
Trac field | Value |
---|---|
Version | 7.4.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | libraries/directory |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |