On 09/21/2016 10:04 AM, FUJIWARA Katsunori wrote:
At Wed, 21 Sep 2016 15:20:39 +0900,
FUJIWARA Katsunori wrote:

At Tue, 20 Sep 2016 18:12:58 +0200,
Pierre-Yves David wrote:

On 09/16/2016 10:51 PM, FUJIWARA Katsunori wrote:
# HG changeset patch
# User FUJIWARA Katsunori <fo...@lares.dti.ne.jp>
# Date 1474057495 -32400
#      Sat Sep 17 05:24:55 2016 +0900
# Node ID 71b6b49f8a7ab6c894028b9153290f4bbf0f54f6
# Parent  ad999fb789fcb86b11c98334ab98b31a17ee2d25
vfs: use checkambigatclosing in checkambig=True but atomictemp=False case

In Mercurial source tree, opening a file in "a"/"a+" mode like below
doesn't specify atomictemp=True for vfs, and this avoids file stat
ambiguity check by atomictempfile.

  - writing changes out in revlog layer uses "a+" mode
  - truncation in repair.strip() uses "a" mode
  - truncation in transaction._playback() uses "a" mode

If steps below occurs at "the same time in sec", all of mtime, ctime
and size are same between (1) and (3).

  1. append data to revlog-style file (and close transaction)
  2. discard appended data by truncation (strip or rollback)
  3. append same size but different data to revlog-style file again

Therefore, cache validation doesn't work after (3) as expected.

This patch uses checkambigatclosing in checkambig=True but
atomictemp=False case, to check (and get rid of) file stat ambiguity
at closing.

This is a part of ExactCacheValidationPlan.


diff --git a/mercurial/scmutil.py b/mercurial/scmutil.py
--- a/mercurial/scmutil.py
+++ b/mercurial/scmutil.py
@@ -587,6 +587,10 @@ class vfs(abstractvfs):
         if nlink == 0:

+        if checkambig:
+            assert mode not in ('r', 'rb'), "valid only at writing"
+            fp = checkambigatclosing(fp)

It sound a bit too much like a real logic check with assert. Instead we
should probably either:
- have a hard check with an abort.
- ignore the bad state with a devel warning (probably the best).

OK, I'll send revised one with the latter.

Oops, I forgot that vfs doesn't have any reference path to ui object :-<

Should we raise Abort('implementation error: mode %s is not valid for
checkambig=True') or so ? (or ignore bad state silently ?)

We could either carry some function to issue this warning, but this seems a bit cumbersome :-/

I'm a bit afraid of raising an Abort as is might eventually backfire on some innocent user. However, silently ignoring it means developer could misuse the API without ever realizing. So I guess we should go with the raise Abort.


Pierre-Yves David
Mercurial-devel mailing list

Reply via email to