Re: [PATCH 2/2] mingw: ensure temporary file handles are not inherited by child processes

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> From: Ben Wijen <ben@wijen.net>
>
> When the index is locked and child processes inherit the handle to
> said lock and the parent process wants to remove the lock before the
> child process exits, on Windows there is a problem: it won't work
> because files cannot be deleted if a process holds a handle on them.
> The symptom:
>
>     Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed.
>     Should I try again? (y/n)
>
> Spawning child processes with bInheritHandles==FALSE would not work
> because no file handles would be inherited, not even the hStdXxx
> handles in STARTUPINFO (stdin/stdout/stderr).
>
> Opening every file with O_NOINHERIT does not work, either, as e.g.
> git-upload-pack expects inherited file handles.
>
> This leaves us with the only way out: creating temp files with the
> O_NOINHERIT flag. This flag is Windows-specific, however. For our
> purposes, it is equivalent our purposes) to O_CLOEXEC (which does not
> exist on Windows), so let's just open temporary files with the
> O_CLOEXEC flag and map that flag to O_NOINHERIT on Windows.

The callchain that leads to create_tempfile() eventually goes up to
hold_lock_file_for_update() and its _timeout() variant in the
current codebase.  There is no other create_tempfile() caller.

I think all the callers of these public entry points use them to
open a lockfile for its own use, and never delegate the writing to
it to their children, so this change is safe right now, and I do not
think it is too bad that a new caller that wants to do that have to
explicitly drop O_CLOEXEC (perhaps by dup(2)ing).

But it deserves mention in the lockfile and the tempfile API docs in
<lockfile.h> and <tempfile.h> that the file descriptor returned from
these public entry points does not survive across fork(2).

Something along the line shown by the attached patch, perhaps.

Other than that, this is very nicely analyzed and discusses possible
alternative approaches sufficiently to easily convince readers that
this is the best solution.

Very nicely done.  Thanks.

 lockfile.h | 4 ++++
 tempfile.h | 4 ++++
 2 files changed, 8 insertions(+)

diff --git a/lockfile.h b/lockfile.h
index 3d30193..e976c7a 100644
--- a/lockfile.h
+++ b/lockfile.h
@@ -55,6 +55,10 @@
  *   * calling `fdopen_lock_file()` to get a `FILE` pointer for the
  *     open file and writing to the file using stdio.
  *
+ *   Note that the file descriptor returned by hold_lock_file_for_update()
+ *   is marked O_CLOEXEC, so the new contents must be written by
+ *   you, and not by your subprocess.
+ *
  * When finished writing, the caller can:
  *
  * * Close the file descriptor and rename the lockfile to its final
diff --git a/tempfile.h b/tempfile.h
index 4219fe4..d357177 100644
--- a/tempfile.h
+++ b/tempfile.h
@@ -33,6 +33,10 @@
  *   * calling `fdopen_tempfile()` to get a `FILE` pointer for the
  *     open file and writing to the file using stdio.
  *
+ *   Note that the file descriptor returned by create_tempfile()
+ *   is marked O_CLOEXEC, so the new contents must be written by
+ *   you, and not by your subprocess.
+ *
  * When finished writing, the caller can:
  *
  * * Close the file descriptor and remove the temporary file by