]> git.ipfire.org Git - thirdparty/git.git/commit - tempfile.c
mingw: ensure temporary file handles are not inherited by child processes
authorBen Wijen <ben@wijen.net>
Mon, 22 Aug 2016 12:47:55 +0000 (14:47 +0200)
committerJunio C Hamano <gitster@pobox.com>
Tue, 23 Aug 2016 16:09:55 +0000 (09:09 -0700)
commit05d1ed6148305d299693000856e4971e9f642662
treef8eb9b5d023d3daeae0a4e4cdf8e006e7c3773bc
parentad65f7e3b71aac841d771cd75392747d6945cc3c
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 <ben@wijen.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
compat/mingw.h
git-compat-util.h
lockfile.h
t/t6026-merge-attr.sh
tempfile.c
tempfile.h