From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55607 invoked by alias); 2 Jan 2019 13:56:52 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 55599 invoked by uid 89); 2 Jan 2019 13:56:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_05,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*u:Webmail, H*UA:Webmail, resolving, exposed X-HELO: lb1-smtp-cloud7.xs4all.net Received: from lb1-smtp-cloud7.xs4all.net (HELO lb1-smtp-cloud7.xs4all.net) (194.109.24.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Jan 2019 13:56:49 +0000 Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:199]) by smtp-cloud7.xs4all.net with ESMTPA id eh0nga6nJVTyleh0ngbazy; Wed, 02 Jan 2019 14:56:46 +0100 Received: from a83-162-234-136.adsl.xs4all.nl ([83.162.234.136]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 02 Jan 2019 14:56:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 02 Jan 2019 13:56:00 -0000 From: Houder To: cygwin@cygwin.com Subject: Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux In-Reply-To: <20181217112603.GV28727@calimero.vinschen.de> References: <0f030e809f063f5a5e64ff7a7a0c3227@xs4all.nl> <20181216202847.GK28727@calimero.vinschen.de> <20181216215549.GO28727@calimero.vinschen.de> <12270f528754c1ce974e6ad8d22c4249@xs4all.nl> <20181217092533.GP28727@calimero.vinschen.de> <20181217112603.GV28727@calimero.vinschen.de> Message-ID: <31836f02efaea936cb0f9c09b0483c56@xs4all.nl> X-Sender: houder@xs4all.nl User-Agent: XS4ALL Webmail X-SW-Source: 2019-01/txt/msg00006.txt.bz2 On 2018-12-17 12:26, Corinna Vinschen wrote: > On Dec 17 10:25, Corinna Vinschen wrote: >> On Dec 17 05:30, Houder wrote: >> > On 2018-12-16 22:55, Corinna Vinschen wrote: >> > [snip] >> > >> > > I'm mulling over adding some hack to open(). It could try to recognize >> > > the special case of opening a processes' own descriptor symlink within >> > > /proc and then warp the open() call into dup(). No idea how tricky >> > > or even feasible that is, though... >> > >> > That is why I wrote the following in my STC: >> > >> > // Q: does Cygwin attempt to read the /tmp directory? (an attempt >> > that >> > // will fail, because the file has been unlinked) >> > // it appears that reading a symlnk in /dev/fd can best be diverted >> > to >> > // the open file descriptor of the process ... >> > >> > What I meant was, that I see no reason to modify the symlink in this >> > special case, but in stead of that to access the file using fd N, where >> > N is equal to the one in /dev/fd/N. >> > >> > File descriptor N has been left open by bash and should not have been >> > closed as result of the exec ... [snip] > The tricky part is to find out when resolving the filename is not > required because we already have a descriptor / HANDLE and how to > proceed from there... Ref: https://cygwin.com/ml/cygwin/2018-12/msg00125.html ( /dev/fd/N not synonymous with file descriptor N; it is on Linux ) For the record only: You were/are right and I was complete wrong: open file descriptor N is only by chance equal to /dev/fd/N ... Neither the semantics of FreeBSD (and Solaris) -- similar to dup() -- nor those of Linux (where the opening of the deleted file results in a new entry in the open file table) are feasible in Cygwin. FreeBSD (Solaris) and Linux require the concept of a "directory cache" to exist in order to make the above possible (that cache must also be exposed to the user in some way). FreeBSD (Solaris): based on the filename, the corresponding open file descriptION is found; a new file descriptor to this entry in the open file table is returned to the user ... It appears as if the inherited open file descriptor is dup'ed, but it is not. Linux: based on the filename, the corresponding inode is found; a new entry in the open file table is created; a file descriptor to the new entry in the open file table is returned to the user ... (this can be verified using kcmp(2) ). The above is not possible in Cygwin. Cygwin cannot follow here. Regards, Henri -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple