thought
This commit is contained in:
parent
13c853bda1
commit
66cb41b0b3
1 changed files with 6 additions and 1 deletions
|
@ -141,7 +141,7 @@ An atomic move could at least narrow the race significantly, eg:
|
|||
conflict has to be resolved. Otherwise, delete $tmp2
|
||||
4. atomic move $tmp1 to $file
|
||||
|
||||
The remaining race is that, if the file is open for write at the same
|
||||
A remaining race is that, if the file is open for write at the same
|
||||
time it's renamed, the write might happen after the content identifer
|
||||
is checked, and then whatever is written to it will be lost.
|
||||
|
||||
|
@ -153,6 +153,11 @@ that it appended to the file got lost:
|
|||
|
||||
Since this is acceptable in git, I suppose we can accept it here too..
|
||||
|
||||
Another remaining race is if the file gets recreated after it's moved out
|
||||
of the way. If the atomic move refuses to overwrite existing files, that race
|
||||
would be detected by it failing. renameat(2) with `RENAME_NOREPLACE` can do that,
|
||||
but probably many special remote interfaces don't provide a way to do that.
|
||||
|
||||
----
|
||||
|
||||
Since exporttree remotes don't have content identifier information yet, it
|
||||
|
|
Loading…
Add table
Reference in a new issue