X-Recipient: archive-cygwin@delorie.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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=GRwPe5nmLeVGj0OnSxBB67dwld+BvNGMe5Rz/FcFZswYfvv69a9lB
	r58gnwMJl+jiZMNtzj0Qc6hY212tm7ldCufCSYAIWGgxwZWSPfY5QMBrLV1/xxD5
	fWdSj0m2Y59NCJEFbdwX0piM73Tl5DLsruyfXuhcT1ZKWeRb3WUDMw=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=4/V/XrmgHZ5ptbSWQDM5yuN2XRo=; b=VKGvZtdyjA6XTfH9F+Y5HpbcSHmi
	g6sFi3zTW7UAWiW53skP1z73BUxjvxScYxRuamMPcuW6uqkOT6Nzl3Ydq5gyER+s
	N8bdY7pu6tMKOlw8I1FiEcecM5MmS4ZxDKFLUfPtoWoUOFWtc5Los2N4AXEws8al
	3CMOjueF0Q90/+o=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=
X-HELO: mout.kundenserver.de
Date: Mon, 17 Dec 2018 12:26:03 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux
Message-ID: <20181217112603.GV28727@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <0f030e809f063f5a5e64ff7a7a0c3227@xs4all.nl> <20181216202847.GK28727@calimero.vinschen.de> <CAHSx_SvqFgi5stKvYSNCPwyyu98miPHyYcDKJL1-=KP8NE9+JQ@mail.gmail.com> <20181216215549.GO28727@calimero.vinschen.de> <12270f528754c1ce974e6ad8d22c4249@xs4all.nl> <20181217092533.GP28727@calimero.vinschen.de>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="Z9t8O/5YJLB6LEUl"
Content-Disposition: inline
In-Reply-To: <20181217092533.GP28727@calimero.vinschen.de>
User-Agent: Mutt/1.9.2 (2017-12-15)

--Z9t8O/5YJLB6LEUl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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]
> >=20
> > > I'm mulling over adding some hack to open().  It could try to recogni=
ze
> > > 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...
> >=20
> > That is why I wrote the following in my STC:
> >=20
> >         // Q: does Cygwin attempt to read the /tmp directory? (an attem=
pt
> > that
> >         //    will fail, because the file has been unlinked)
> >         // it appears that reading a symlnk in /dev/fd can best be dive=
rted
> > to
> >         // the open file descriptor of the process ...
> >=20
> > 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.
> >=20
> > File descriptor N has been left open by bash and should not have been
> > closed as result of the exec ...
>=20
> tl;dr:
>=20
>   cat tries to open /dev/fd/0.  /dev/fd/0 refers to a non-existing
>   file and that's why open fails.  Cygwin doesn't have special code to
>   handle the fd symlinks as refference to an actually open descriptors.
>=20
> The long story:
>=20
>   The descriptor hasn't been closed.  Cat still has the file open as fd 0.
>=20
>   The problem is that you tell cat to open and read from /dev/fd/0,
>   *not* from fd 0.  That's quite a difference.  /dev/fd/0 is just some
>   arbitrary file which is given to open(2), a symlink at that.  First
>   thing open(2) does is to call the symlink evaluation code.  The
>   symlink is ultimately evaluated to the filename opened by the shell.

I just tested this on Linux.  Basically, open(2) in Cygwin is equivalent
to calling readlink(2); open(2):

  readlink(incoming_filename, resolved_filename, ...);
  open (resolved_filename, ...);

If I do this on Linux with a cat-clone calling readlink before calling
open, the error returned by open(2) is the same as on Cygwin, ENOENT.

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


Corinna

--=20
Corinna Vinschen
Cygwin Maintainer

--Z9t8O/5YJLB6LEUl
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlwXh8sACgkQ9TYGna5E
T6DtsQ//RIyK4oop1m9IkZR5iDZ7vCIhMH9rCwS7R60BpyRSHUlrSeN0Kg67rFCE
L5VlnJpopaj/MvzXQGXyImsOblnIXoHgfM84N8gEfP6I50GIbQBYnc0/7BhBCzo3
vw/+wsLihs8fAokOSBnqiUNUoc9MpB6Z+sy0uLdiCqp1kTFDknxuj4VbaZ0HiIBg
1p+pjcwLqL3MW4jPvA5MjTd28besjCrMhYR21Oo+IhMcqEkvKvx4hlbHIaym1VVK
QNxszkYUqqAl0rak8aNFkLVQ3GpuhbcxRqqIcayPB1+OPkigDvU9KPCzGyCd98Gj
15BtWnZSxJ7UFv0mYWEGQTg6UzZQf1fmaGu7P+N5QfvootqpcG5CnRr5JVTqaqik
OxO/apCOMpZ3EB8XC0Ahw97hA3yXNRJzMCs1erTFNeACAdztJGJjGJqQ26EF64qX
qKCCQCqQZ3jWmMOujKkw7UZwy7tewn7iDDQ/xNmSfIxUO/zvj7qkkvPbm7CdwAL+
J/KIAbXDkGgpVskRLcG3kdLup0o+v1jsiMGKoYC2qUdiWaFCoa/6fc+xFfD3x8uU
UUqUYQCIdrwCfimdMZdcowu+NUwqO/LVZ272KskJde0e5IHzu4D6Um1DRt4Im/Wq
XArS/eskgEuEXWMEe0Yt4qT49gRynr1WXz1B9sKD0vuMsIMB3/Y=
=mehp
-----END PGP SIGNATURE-----

--Z9t8O/5YJLB6LEUl--
