From: Johannes Schindelin <Johannes.Schindelin@gmx.de> To: Junio C Hamano <firstname.lastname@example.org> Cc: Johannes Schindelin via GitGitGadget <email@example.com>, firstname.lastname@example.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.email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi Junio, On Mon, 25 Nov 2019, Junio C Hamano wrote: > "Johannes Schindelin via GitGitGadget" <email@example.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. > >
prev parent reply other threads:[~2019-11-25 16:29 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-22 14:41 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 ` [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes Junio C Hamano 2019-11-25 16:29 ` Johannes Schindelin [this message]
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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=nycvar.QRO.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/4] On Windows, limit which file handles are inherited by spawned child processes' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).