Read about our upcoming Code of Conduct on this issue

This instance will be upgraded to Heptapod 0.28.0 on 2022-01-18 at 14:00 UTC+1 (a few minutes of down time)

Commit 63945e2a authored by Pierre-Yves David's avatar Pierre-Yves David 🐙
Browse files

status: move the boundary comparison logic within the timestamp module

Some extensions will need it too. So lets isolate the logic. It also makes
things clearer.

Differential Revision: https://phab.mercurial-scm.org/D11799
parent eea70e3539ed
......@@ -1823,29 +1823,12 @@ class workingctx(committablectx):
s = self[f].lstat()
mode = s.st_mode
size = s.st_size
file_mtime = timestamp.mtime_of(s)
cache_info = (mode, size, file_mtime)
file_second = file_mtime[0]
boundary_second = mtime_boundary[0]
# If the mtime of the ambiguous file is younger (or equal)
# to the starting point of the `status` walk, we cannot
# garantee that another, racy, write will not happen right
# after with the same mtime and we cannot cache the
# information.
#
# However is the mtime is far away in the future, this is
# likely some mismatch between the current clock and
# previous file system operation. So mtime more than one days
# in the future are considered fine.
if (
boundary_second
<= file_second
< (3600 * 24 + boundary_second)
):
clean.append(f)
else:
file_mtime = timestamp.reliable_mtime_of(s, mtime_boundary)
if file_mtime is not None:
cache_info = (mode, size, file_mtime)
fixup.append((f, cache_info))
else:
clean.append(f)
except (IOError, OSError):
# A file become inaccessible in between? Mark it as deleted,
# matching dirstate behavior (issue5584).
......
......@@ -99,3 +99,28 @@ def mtime_of(stat_result):
subsec_nanos = nanos % billion
return timestamp((secs, subsec_nanos))
def reliable_mtime_of(stat_result, present_mtime):
"""same as `mtime_of`, but return None if the date might be ambiguous
A modification time is reliable if it is older than "present_time" (or
sufficiently in the futur).
Otherwise a concurrent modification might happens with the same mtime.
"""
file_mtime = mtime_of(stat_result)
file_second = file_mtime[0]
boundary_second = present_mtime[0]
# If the mtime of the ambiguous file is younger (or equal) to the starting
# point of the `status` walk, we cannot garantee that another, racy, write
# will not happen right after with the same mtime and we cannot cache the
# information.
#
# However is the mtime is far away in the future, this is likely some
# mismatch between the current clock and previous file system operation. So
# mtime more than one days in the future are considered fine.
if boundary_second <= file_second < (3600 * 24 + boundary_second):
return None
else:
return file_mtime
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment