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 |