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: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 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=-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 AT cygwin DOT com>
To:	cygwin AT cygwin DOT 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 AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<0f030e809f063f5a5e64ff7a7a0c3227 AT xs4all DOT nl> <20190106201950 DOT GC4430 AT calimero DOT vinschen DOT de> <d6431739e2801a80d73e7cb68b4fcc19 AT smtp-cloud8 DOT xs4all DOT net> <1c60402837d6510667357257b5e96e88 AT xs4all DOT nl> <20190122090633 DOT GK2802 AT calimero DOT vinschen DOT de> <151898514e462bd76cda8a227d4baa16 AT xs4all DOT nl>
MIME-Version:	1.0
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--

- Raw text -