# HG changeset patch # User Pierre-Yves David # Date 1637114324 -3600 # Node ID c655483ea6e21562af96d3397575093cf255ae59 # Parent ad5a644738400f8b87c788fa8b96f68c7a80405c dirstate: add a comment about a racy piece of code during updates This is a bit that is not really correct but works "fine" in practice. Let us write the details down so that people stop wondering how that logic might be correct… It is not. Differential Revision: https://phab.mercurial-scm.org/D11781 diff -r ad5a64473840 -r c655483ea6e2 mercurial/merge.py --- a/mercurial/merge.py Mon Oct 25 15:11:53 2021 +0200 +++ b/mercurial/merge.py Wed Nov 17 02:58:44 2021 +0100 @@ -1404,6 +1404,34 @@ atomictemp=atomictemp, ) if wantfiledata: + # XXX note that there is a race window between the time we + # write the clean data into the file and we stats it. So another + # writing process meddling with the file content right after we + # wrote it could cause bad stat data to be gathered. + # + # They are 2 data we gather here + # - the mode: + # That we actually just wrote, we should not need to read + # it from disk, (except not all mode might have survived + # the disk round-trip, which is another issue: we should + # not depends on this) + # - the mtime, + # On system that support nanosecond precision, the mtime + # could be accurate enough to tell the two writes appart. + # However gathering it in a racy way make the mtime we + # gather "unreliable". + # + # (note: we get the size from the data we write, which is sane) + # + # So in theory the data returned here are fully racy, but in + # practice "it works mostly fine". + # + # Do not be surprised if you end up reading this while looking + # for the causes of some buggy status. Feel free to improve + # this in the future, but we cannot simply stop gathering + # information. Otherwise `hg status` call made after a large `hg + # update` runs would have to redo a similar amount of work to + # restore and compare all files content. s = wfctx.lstat() mode = s.st_mode mtime = timestamp.mtime_of(s)