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: ericblake AT comcast DOT net (Eric Blake)
Cc: bug-coreutils AT gnu DOT org, cygwin AT cygwin DOT com
Subject: Re: mkdir -p and EROFS
In-Reply-To: <101220051447.16978.434D21E5000D25EB0000425222007610640A050E040D0C079D0A@comcast.net> 	(Eric Blake's message of "Wed, 12 Oct 2005 14:47:01 +0000")
References: <101220051447 DOT 16978 DOT 434D21E5000D25EB0000425222007610640A050E040D0C079D0A AT comcast DOT net>
Date: Wed, 12 Oct 2005 19:45:40 +0200
Message-ID: <87br1ubpdn.fsf@rho.meyering.net>
Lines: 45
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

ericblake AT comcast DOT net (Eric Blake) wrote:
> The algorithm change between 5.3.0 and 5.90 in lib/mkdir-p.c to
> try mkdir() first instead of stat(), and key off of EEXIST, breaks
> when mkdir() fails with EROFS on an intermediate directory when
> the writable directory has been mounted inside a read-only tree.

Are you sure 5.3.0 behaved differently in this case?
The recent algorithm change was merely to eliminate the optimization
of initially stat'ing the full directory name.  In your example,
that stat would fail and the function would end up performing the same
operations the 5.90 version performs.

> For example, on cygwin:
>
> $ mkdir -p //EBLAKE/share/dir
> mkdir: cannot create directory `//EBLAKE': Read-only file system
>
> where // and //EBLAKE are read-only, //EBLAKE/share exists and
> is writable, and //EBLAKE/share/dir does not exist.  The failure
> comes because mkdir("//EBLAKE") fails with EROFS, which, as far
> as I can tell, is permitted by POSIX since // (the parent of
> //EBLAKE) is not writable, even though I would have preferred
> EEXIST.
>
> I have already raised this with the cygwin developers, who
> have expressed their desire to leave things as is rather than
> trying to return EEXIST in the case that an intermediate
> directory in the read-only file system exists, as it is much faster
> to blindly return EROFS than to stat the directory name to check
> for existance.  So is it worth a patch to mkdir-p.c to treat EROFS
> as an indicator to perform a followup stat() (similar to the ENOSYS
> hack used for NFS mounts on Solaris)?

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

If mkdir-p.c were to handle Cygwin's EROFS like ENOSYS, we'd have to add
code to distinguish a legitimate EROFS (because a missing destination
directory cannot be created) from a cygwin-style should-be-EEXIST one.
That feels too kludgy.

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