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=rjOM9l3eYc5mcvVo/suj5b9TOHwudD6bWJuoh3Du2uYtVkiK3ykUS
	fqb5bO9EO1Wq1NAyFXSxGF9R6lV+qS/i+5CuK3eNZ0/0/4TN2Xk1QJkaRIxygL/3
	lExsXYu4fH39cnZ2v8tYRsHmCCCyG61XYwqeWbDp0pS2fmEyAojoZE=
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=x0z4J/0RXnT1R8hYguAOwZ2ChZc=; b=UCx3hgNbOyeATvEuTF0ImITtGuBA
	m8cxY5iLjlOgCn7K7h2KLeC2r70EgXNUcRNcSta8ZOJG0haquJxjESvg8qwlb1S9
	H46zE8/AIVhSEpaOWAM+jQfcVZPOs3aU7suzXctE9lYpgK/VOJ9xCICddTnxcsad
	Pz2u9BB7LrJa9xU=
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,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=resort, H*i:sk:1518985, H*f:sk:1518985, ATM
X-HELO: mout.kundenserver.de
Date: Tue, 22 Jan 2019 10:41:57 +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: <20190122094157.GN2802@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <0f030e809f063f5a5e64ff7a7a0c3227@xs4all.nl> <20190106201950.GC4430@calimero.vinschen.de> <d6431739e2801a80d73e7cb68b4fcc19@smtp-cloud8.xs4all.net> <1c60402837d6510667357257b5e96e88@xs4all.nl> <20190122090633.GK2802@calimero.vinschen.de> <151898514e462bd76cda8a227d4baa16@xs4all.nl>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="JkW1gnuWHDypiMFO"
Content-Disposition: inline
In-Reply-To: <151898514e462bd76cda8a227d4baa16@xs4all.nl>
User-Agent: Mutt/1.10.1 (2018-07-13)

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

On Jan 22 10:25, Houder wrote:
> On 2019-01-22 10:06, Corinna Vinschen wrote:
> > On Jan 22 09:57, Houder wrote:
> > > On 2019-01-22 09:50, Houder wrote:
> > > > On Sun, 6 Jan 2019 21:19:50, Corinna Vinschen  wrote:
> > > > > This should work in the latest developer snapshot uploaded to
> > > > > https://cygwin.com/snapshots/  Please give it a try.
> > > > So, for the record only:
> > >=20
> > > and as another example, this STC succeeds on Linux ..., but fails on
> > > Cygwin.
> > >=20
> > > 64-@@ ./stca /dev/fd/0 <<EOF
> > > > bla
> > > > EOF
> > > fd1 =3D 0
> > > argv[1] =3D /dev/fd/0
> > > fd2 =3D 3
> > > id =3D writefd2, errno =3D 13, errstr =3D Permission denied
> > > 64-@@
> >=20
> > Not sure what you're testing.  This is the result for me on both,
> > Windows 8.1 and Windows 10 1809:
>=20
> Curious! It fails (for me) on W7 ...

It works for me just as well on W7:

$ uname -a
CYGWIN_NT-6.1 vmbert764 2.12.0(0.333/5/3) 2019-01-21 22:47 x86_64 Cygwin
$ ./stca /dev/fd/0 <<EOF
? bla
? EOF
fd1 =3D 0
argv[1] =3D /dev/fd/0
fd2 =3D 3
buf =3D \
Hello, world!

> > Not sure what you're testing.
>=20
> STC inherits a "read-only" open file descriptor from bash. On Linux
> the file can be opened read-write (via procfs), because a new entry
> is created in the open file table.
>=20
> (opening the file read-write (via fdescfs) on FreeBSD would fail)
>=20
> For this reason the output does not show what has been entered via
> the here-doc.
>=20
> In short, I was merely testing the semantics of Linux.

Ah, ok.  This is a bit of a problem on Windows.  The code tries to
reopen the file by handle.  Under some circumstances(*) we can't reopen
the file.  In that case the code just tries to duplicate the handle.
However, a duplicated file handle can't have more permissions than the
original handle.

So if it fails for you, it seems the reopen failed and the handle
only got duplicated.  In that case, you can't gain write perms if
the original handle only got read perms.

What the code fails to do is trying to open the file by name as a last
resort.  There was a (good?) reason I didn't implement that, but I don't
remember ATM.


Corinna

(*) E.g., deleted files on systems older than Windows 10 1709,
    or files on filesystems not supporting the "reopen-by-handle"
    semantics.  However, the latter case should work at least
    for non-deleted files

--=20
Corinna Vinschen
Cygwin Maintainer

--JkW1gnuWHDypiMFO
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlxG5WUACgkQ9TYGna5E
T6AAqg//XL/vJkSfU4NQ/ROXXuC6yM8YsnRBMx1cXhsaC1bT8s7xsEnkxPXyV/mq
TEa1mJKzg76CBMBwHxmtIsDSkTUtSAp9QT/UPUYWtFcz1a6Ksa+4THVuQPM32cQw
L/kjJHd4XBC9AWskrXWl5KDYBe6o4zamghk3PIUF4+tE67BmTlT/o6KlDP7iK30d
b9PwaoVEBy9yuAYkLtwbna7+6/SfOY7nUn2cHZgRHNU/uA0l06VYv2x8U8IO3M0m
nMX0EaQtzZIatmJlOlBq3J5EsjTjI0ZIFtS5CwtpS0gOLZUVBDkNbiDSPTba5w5w
V0Dp2t+N+kDfApFDrVLC/j4AkboHKPfBAe7DehVD7DZKpUcgbrPikU13Fs5L27U2
QZjKfHburwjDQKAEO2k281rkQIliGOP3zhhqPBk4PAO9D0Yg455LrCSaZVvcUtfg
StaDRbM2KkJwpwFbPpIt88Bn4mIS8RSHYyc95sibyndpNhJeH3ucY1mX5tVpExt4
hOLuJ2slXUqWS9kJjTbwKu0R61Sve1rfbv62BEjgNmByqmP+JrW84i7kQz1ZLwZ7
i4Y0H0h6MjVKDvS/V0RU9WaE2/Y2vDyYfpPJ1jCPUrcfHhJmaAVDXRwGfAAeGAyN
tXHEdzUNCNnl/Yj6i/BC0vdmzINpLP/U6gEDPtOC0pG1w70ALTE=
=BGa3
-----END PGP SIGNATURE-----

--JkW1gnuWHDypiMFO--