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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2016, 18:22 UTC
Message-ID: <xmqqd1l79rxz.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <77e7c4e4de6c45a1b24bb4d08ca20a1385f43444.1471437637.git.johannes.schindelin@gmx.de>

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

Show 23 quoted lines

> 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