From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id 9E97639AC879 for ; Sat, 6 Feb 2021 07:56:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9E97639AC879 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: from localhost (mark@localhost) by m0.truegem.net (8.12.11/8.12.11) with ESMTP id 1167uv1i020819 for ; Fri, 5 Feb 2021 23:56:57 -0800 (PST) (envelope-from mark@maxrnd.com) X-Authentication-Warning: m0.truegem.net: mark owned process doing -bs Date: Fri, 5 Feb 2021 23:56:57 -0800 (PST) From: Mark Geisert X-X-Sender: mark@m0.truegem.net To: Corinna Vinschen via Cygwin-developers Subject: Re: Extending domain of O_TMPFILE? In-Reply-To: <20210205112650.GO4251@calimero.vinschen.de> Message-ID: References: <20210205112650.GO4251@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2021 07:57:09 -0000 On Fri, 5 Feb 2021, Corinna Vinschen via Cygwin-developers wrote: > On Feb 5 02:31, Mark Geisert wrote: >> Hi folks, >> I've been following up on a response I made to a Cygwin user in >> https://cygwin.com/pipermail/cygwin/2021-January/247306.html . >> I've figured out that Cygwin's implementation of the open() flag O_TMPFILE >> follows Linux in that one can't specify the name of a file when using this >> flag. User supplies only the path, and Cygwin chooses an obscure file name >> for you. >> >> That means the OP's suggested improvement of applying O_TMPFILE semantics to >> files created by tmpfile() won't work. > > I don't understand the problem. tmpfile(3) does not take filenames, it > creates its own filenames. Thus, just adding O_TMPFILE in _tmpfile_r's > and _tmpfile64's calls to open() on systems supporting this flag and not > calling _remove_r subsequently would already do the trick. That's what I thought too. But the open() fails and strace reveals ENOENT is being generated at syscalls.cc:1516. The unix_path arg to open() needs to indicate a directory, but _tmpfile_r is currently passing in a filename path generated by _tmpnam_r. So that's what led me to contemplate extending the domain of O_TMPFILE such that one could proactively name the temporary file. But it's probably more sane to just have _tmpfile_r skip the generation of a file name and instead pass in a directory name to open(), either from environment variable TMPDIR or the libc #define P_tmpdir. Does this sound OK? Thanks, ..mark