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: ericblake AT comcast DOT net (Eric Blake)
To: cygwin AT cygwin DOT com
Subject: Re: mkdir(2) bug [Was: please test: coreutils-5.90-2]
Date: Wed, 12 Oct 2005 14:33:36 +0000
Message-Id: <101220051433.21953.434D1EC0000B3929000055C122007610640A050E040D0C079D0A@comcast.net>

> > On Oct 12 06:58, Eric Blake wrote:
> > > I see the following bugs:
> > > 
> > > $ ./foo //   # should fail with EEXIST, not EROFS; no Windows call made
> > 
> > We had this already.  There's no such thing as a "correct" order of error
> > messages.  EROFS is as correct as EEXIST.  If coreutils don't allow
> > different correct error messages to be returned, than coreutils is just
> > not foolproof enough.  If this isn't a problem with coreutils, than the
> > better.
> 
> OK, for //, you win - POSIX requires EROFS ONLY if the PARENT directory
> is read only, but the parent of // is //.  Fortunately, mkdir -p never
> tries to do mkdir("//").

Followup - this behavior of returning EROFS breaks
mkdir -p //server/share in 5.90.  Returning EEXIST really would be more
appropriate, but I will file an upstream bug to see whether they agree
that EROFS should be treated as a reason to call stat() to see if it
should have been EEXIST, rather than blindly failing on EROFS (this
affects non-cygwin systems, too, since you can mount writable
directories inside a read-only system).

--
Eric Blake


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