X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; q=dns; s=default; b=SiryCDImS63v4GMMT7RS
	vChgyLuh6oJ+4DxSgkYw76pWthBebQhPTiktysGM4ujwCxEtRBN2z88UP1+GHMdV
	WEOVXqRoCP5UtoRzD2rSZj3lOyxgS0vCMketTAlBvHaw9wG+3W1JEa1q2Z1wkjIR
	HHG1+vrM2CeNV6ePsfekQ20=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:content-type
	:content-transfer-encoding:date:from:to:subject:in-reply-to
	:references:message-id; s=default; bh=HCBdHEACqY5WyYeP19SBx8N40j
	k=; b=EC+0URkcYgFfbQvMp/d0d6H+BQ/mUf29Rh18dqHRAf/hRVP9rXYRw8z9Ja
	EN3eMG2cqvD6/inhv1/idWHeKpYPzNnNdKbN1zEgCFBit7D6R/PhgeYuQblCEfVN
	KL9K6n3beRoT+teA7kAglEToe6nMJvOr17sRLJQPLFBGQ1QgA=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
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
MIME-Version:	1.0
Date:	Wed, 02 Jan 2019 14:56:45 +0100
From:	Houder <houder AT xs4all DOT nl>
To:	cygwin AT cygwin DOT 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 AT xs4all DOT nl> <20181216202847 DOT GK28727 AT calimero DOT vinschen DOT de> <CAHSx_SvqFgi5stKvYSNCPwyyu98miPHyYcDKJL1-=KP8NE9+JQ AT mail DOT gmail DOT com> <20181216215549 DOT GO28727 AT calimero DOT vinschen DOT de> <12270f528754c1ce974e6ad8d22c4249 AT xs4all DOT nl> <20181217092533 DOT GP28727 AT calimero DOT vinschen DOT de> <20181217112603 DOT GV28727 AT calimero DOT vinschen DOT de>
Message-ID:	<31836f02efaea936cb0f9c09b0483c56@xs4all.nl>
X-Sender:	houder AT xs4all DOT nl
User-Agent:	XS4ALL Webmail

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

- Raw text -