Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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
From: Jim Meyering <jim AT meyering DOT net>
To: cygwin AT cygwin DOT com
Cc: bug-coreutils AT gnu DOT org
Subject: Re: mkdir -p and EROFS
In-Reply-To: <20051012181743.GE20361@trixie.casa.cgf.cx> (Christopher Faylor's 	message of "Wed, 12 Oct 2005 14:17:43 -0400")
References: <101220051447 DOT 16978 DOT 434D21E5000D25EB0000425222007610640A050E040D0C079D0A AT comcast DOT net> 	<87br1ubpdn DOT fsf AT rho DOT meyering DOT net> 	<20051012181743 DOT GE20361 AT trixie DOT casa DOT cgf DOT cx>
Date: Thu, 13 Oct 2005 09:35:36 +0200
Message-ID: <87psq9g987.fsf@rho.meyering.net>
Lines: 53
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com> wrote:
...
>>IMHO, it is the kernel's job to provide an informative and, above all,
>>compatible-with-most-others errno value, unless there is a very
>>good reason.  The small extra expense of an lstat call (*but only upon
>>failure with errno == EROFS*) doesn't seem to justify their decision,
>
> mkdir() doesn't use lstat.  The right way to fix this within cygwin
> means modifying some lower level path code.

So it'd be disruptive?
Since Eric Blake mentioned that the rationale for not making the
EROFS->EEXIST change was performance, I was suggesting that the
cost (in decreased efficiency) might be small, and incurred only
in an error case.

>>but I do have to admit that this example seems contrived.  Are there
>>`real' environments that use a set-up like you describe, with a writable
>>file system mounted inside a read-only one?
>
> We are close to a Cygwin 1.5.19 release and I would rather not add a
> potentially destabilizing change to the cygwin path code at this point.
> I'm not against reevaluating this after 1.5.19 is released.

Ahh... no one mentioned pre-release stability as a reason for not
making the change.  That's perfectly reasonable.  I can relate :-)

> I am curious about the criteria that you use for accommodating the
> quirks of the operating systems that coreutils supports, however.

If you've followed coreutils development at all, you know that I'm
ready to jump through hoops to work around many types of OS bugs.
But Cygwin is a little different from e.g., Solaris, in that we assume
we need to support versions from only 1 or maybe 2 years back, and even
then, I've heard that it's relatively easy to tell people `upgrade'.
We've done the same with some Linux bugs, too.  I know there's at
least one relating to a buggy linux-2.6.x sleep(2) implementation,
but Linux was fixed shortly thereafter.

> Right now, Cygwin does work the way that Eric describes.  If we changed
> Cygwin to behave differently that would mean that there would be a
> version of coreutils which would only work in newer Cygwins.

Why not, if the conditions that provoke the bug are as obscure as this
(writable mount in a mounted-read-only tree).  Coreutils has required
fchdir for a couple of years now, and older versions of Cygwin lack
that function.  But the point is moot, since Paul found a clean way
to work around the problem.

> If this was an issue with Linux would you be advocating changing Linux?

If Linux did what looked like the wrong thing, and was different
from every other system, then yes.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/