[PATCH 3 of 7] vfs: create copy at renaming to avoid file stat ambiguity if needed

[Yuya Nishihara]

On Fri, 09 Jun 2017 13:08:23 +0900, FUJIWARA Katsunori wrote:
> # HG changeset patch
> # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
> # Date 1496980698 -32400
> #      Fri Jun 09 12:58:18 2017 +0900
> # Node ID 650b77396c6ea684d7ffca6c5e0921482eaffd49
> # Parent  5ae5c4d392374e41d489d87a9d7c1a85920e0702
> vfs: create copy at renaming to avoid file stat ambiguity if needed

> diff --git a/mercurial/vfs.py b/mercurial/vfs.py
> --- a/mercurial/vfs.py
> +++ b/mercurial/vfs.py
> @@ -174,6 +174,7 @@ class abstractvfs(object):
>          only if destination file is guarded by any lock
>          (e.g. repo.lock or repo.wlock).
>          """
> +        srcpath = self.join(src)
>          dstpath = self.join(dst)
>          oldstat = checkambig and util.filestat(dstpath)
>          if oldstat and oldstat.stat:
> @@ -184,9 +185,13 @@ class abstractvfs(object):
>                      # stat of renamed file is ambiguous to original one
>                      return ret, newstat.avoidambig(dpath, oldstat)
>                  return ret, True
> -            ret, avoided = dorename(self.join(src), dstpath)
> +            ret, avoided = dorename(srcpath, dstpath)
> +            if not avoided:
> +                # simply copy to change owner of srcpath (see issue5418)
> +                util.copyfile(dstpath, srcpath)

Is there any chance that the srcpath, which was freed by the previous rename,
could be reused by another process? I'm just asking because I don't know it's
possible in practice.