All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes
Date: Mon, 25 Nov 2019 14:42:02 +0900	[thread overview]
Message-ID: <xmqqimn8y0k5.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <pull.670.git.git.1574433665.gitgitgadget@gmail.com> (Johannes Schindelin via GitGitGadget's message of "Fri, 22 Nov 2019 14:41:01 +0000")

"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.  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.


  parent reply	other threads:[~2019-11-25  5:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-22 14:41 [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes Johannes Schindelin via GitGitGadget
2019-11-22 14:41 ` [PATCH 1/4] mingw: demonstrate that all file handles are inherited by " Johannes Schindelin via GitGitGadget
2019-11-22 14:41 ` [PATCH 2/4] mingw: work around incorrect standard handles Johannes Schindelin via GitGitGadget
2019-11-22 14:41 ` [PATCH 3/4] mingw: spawned processes need to inherit only " Johannes Schindelin via GitGitGadget
2019-11-28 21:48   ` Johannes Sixt
2019-11-29 13:52     ` Johannes Schindelin
2019-11-29 20:40       ` Johannes Schindelin
2019-11-29 22:19       ` Johannes Sixt
2019-11-29 22:37       ` Johannes Sixt
2019-11-30 22:10         ` Johannes Schindelin
2019-11-22 14:41 ` [PATCH 4/4] mingw: restrict file handle inheritance only on Windows 7 and later Johannes Schindelin via GitGitGadget
2019-11-25  5:42 ` Junio C Hamano [this message]
2019-11-25 16:29   ` [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqimn8y0k5.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johannes.schindelin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.