DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:reply-to:to:subject:date:message-id
	:references:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=LlomOfUvHsiBRs0Egzcx6G3VOMrHw
	KKV+K17ONlj+/n6+e8KD4xxT5f/z22HOXQ/IC57PubEU02ZNpvkvoY+gzkPEeqqA
	Jh4T5DZ4z69k7zMPTBNGVyA+JNPtIR5THvHe1wabElhy6eI2C6LZuXfdWzngq0n0
	dIkzZKpPTkWfFY=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
From: "Stephen Provine via cygwin" <cygwin AT cygwin DOT com>
Reply-To: Stephen Provine <stephpr AT microsoft DOT com>
To: Ken Brown <kbrown AT cornell DOT edu>, "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: RE: Future setup regression caused by 'mkdir: always check-for-existence' commit
Date: Mon, 26 Aug 2019 17:33:15 +0000
Message-ID: <MWHPR21MB0845636B4E90AAC4F4BF959EB9A10@MWHPR21MB0845.namprd21.prod.outlook.com>
References: <MWHPR21MB08452B51987E8A239851F7BEB9A10 AT MWHPR21MB0845 DOT namprd21 DOT prod DOT outlook DOT com> <860a3bd2-fc37-27c0-54f3-0fce8add7c24 AT cornell DOT edu>
In-Reply-To: <860a3bd2-fc37-27c0-54f3-0fce8add7c24@cornell.edu>
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-userprincipalname: 3Cqrtp6ZW0vwmJZN/fasFvpqWk6mRlj+g71MQM9J+bmE4kWeYe5PnEGXkcom/bTFOI5GizlLB71X3bFG7Ar6dQ==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id x7QHXppx016683

It's possible that this issue contributes to the problem, but the fact that you can manually create the "dev" directory outside of Cygwin (just mkdir from Windows command prompt) to fix the problem tells me otherwise. If I understand the logic change in commit b0c033bf3fae810b9e5a5c69f17bd4de63725691, it would indicate to me that "mkdir 0755 /dev" in a post-install bash script (regardless of which one) would no longer work when it previously worked. This ultimately means that the /dev/fd directory does not exist and that files like /dev/fd/63 cannot be created (the underlying error is "Filesystem is read-only", because the "dev" directory doesn't actually exist except in Cygwin). It's quite possible that if /dev/fd/63 can be created that there are some subsequent FIFO issues, but in this case the file can't even be created in the first place.

I'd be happy to try the test release for cygwin-3.1.0, but I don't know how to find it. Can you provide a link?

Thanks,
Stephen

-----Original Message-----
From: Ken Brown <kbrown AT cornell DOT edu> 
Sent: Monday, August 26, 2019 10:04 AM
To: cygwin AT cygwin DOT com
Cc: Stephen Provine <stephpr AT microsoft DOT com>
Subject: Re: Future setup regression caused by 'mkdir: always check-for-existence' commit

On 8/26/2019 11:25 AM, Stephen Provine via cygwin wrote:
> After this change (commit b0c033bf3fae810b9e5a5c69f17bd4de63725691), the Git for Windows setup (and future Cygwin setups) do not correctly configure bash features because the post-install step for configuring the /dev directory does not work any more. It used to be that "mkdir -m 755 /dev" would succeed, but now it returns a "File exists" error, after which attempts to create the 'shm' and 'mqueue' directories fail and the /dev/fd, /dev/std{in,out,err} links are not created. This causes some bash features to not work. The fix (validated on Git for Windows) would be for setups to pre-create this directory outside of the Cygwin environment before running the post-install steps.
> 
> See https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgit-for-windows%2Fgit%2Fissues%2F2291%23issuecomment-524433693&amp;data=02%7C01%7Cstephpr%40microsoft.com%7C227fabc69f4e434ae12a08d72a4763d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637024358495313120&amp;sdata=16rboEMc6kGEAzIWDGTjjg%2FVLeuguIbBh%2F9cJMl0oZI%3D&amp;reserved=0 for the in-depth analysis. Note, this is not a current issue in Cygwin, but is believed to become a FUTURE issue with the next release.

It looks like you've bumped into the bug reported here:

   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcygwin.com%2Fml%2Fcygwin%2F2019-07%2Fmsg00152.html&amp;data=02%7C01%7Cstephpr%40microsoft.com%7C227fabc69f4e434ae12a08d72a4763d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637024358495313120&amp;sdata=Ua%2BocDgveO3LqqSP0SnzemAihSysyV3jvae5WMxVA1M%3D&amp;reserved=0

This was a bug in a development snapshot, and it has already been fixed.  You should try the test release for cygwin-3.1.0 to confirm this.

I don't think this problem has anything to do with commit b0c033bf3fae810b9e5a5c69f17bd4de63725691.

Ken

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