[PATCH 3 of 7] vfs: use checkambigatclosing in checkambig=True but atomictemp=False case

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Sep 20 12:12:58 EDT 2016



On 09/16/2016 10:51 PM, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at 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.
>
>     https://www.mercurial-scm.org/wiki/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:
>              self._fixfilemode(f)
>
> +        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).

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list