path: root/lockfile.h
diff options
authorBen Wijen <>2016-08-22 12:47:55 (GMT)
committerJunio C Hamano <>2016-08-23 16:09:55 (GMT)
commit05d1ed6148305d299693000856e4971e9f642662 (patch)
treef8eb9b5d023d3daeae0a4e4cdf8e006e7c3773bc /lockfile.h
parentad65f7e3b71aac841d771cd75392747d6945cc3c (diff)
mingw: ensure temporary file handles are not inherited by child processes
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 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. As Eric Wong pointed out, we need to be careful to handle the case where the Linux headers used to compile Git support O_CLOEXEC but the Linux kernel used to run Git does not: it returns an EINVAL. This fixes the test that we just introduced to demonstrate the problem. Signed-off-by: Ben Wijen <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 'lockfile.h')
1 files changed, 4 insertions, 0 deletions
diff --git a/lockfile.h b/lockfile.h
index 3d30193..d26ad27 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 the
+ * current process, not a spawned one.
+ *
* When finished writing, the caller can:
* * Close the file descriptor and rename the lockfile to its final