Re: [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes

From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes
Date: Mon, 25 Nov 2019 17:29:07 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1911251727560.31080@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqqimn8y0k5.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Mon, 25 Nov 2019, Junio C Hamano wrote:

> "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
> writes:
>
> > The problem to be solved: files cannot be deleted on Windows when even one
> > process has an open file handle to it. So when a process opens a temporary
> > file, then spawns a child process that inherits that file handle by mistake,
> > and then the parent process tries to delete the temporary file while the
> > child process is still running, the deletion will fail. (This description is
> > slightly simplified, see the commit message "spawned processes need to
> > inherit only standard handles" for more detail.)
>
> Makes me wonder if we should be marking these fds with FD_CLOEXEC to
> solve the issue in a way that is platform agnostic.

I would like that a lot.

Having said that, it is too easy to miss when a patch forgets to do that
and when the contributor only tests on Linux. So I really also would like
to keep the current patch in addition.

Thanks,
Dscho

> It may turn out that we'd be better off to make it an explicit choice by
> the parent when it leaves a FD open while spawning a child process (and
> by that spawned child when it runs another executable---but I undertand
> that it is a single-step operation, not a two-step one, on Windows).
>
> In any case, synchronizing the differences in compat/ between our
> trees is good.  Queued.
>
>