Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com To: bug-coreutils@gnu.org Cc: ericblake@comcast.net (Eric Blake), cygwin@cygwin.com Subject: Re: mkdir -p and EROFS References: <101220051447.16978.434D21E5000D25EB0000425222007610640A050E040D0C079D0A@comcast.net> <87br1ubpdn.fsf@rho.meyering.net> From: Paul Eggert Date: Thu, 13 Oct 2005 00:02:06 -0700 In-Reply-To: <87br1ubpdn.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 12 Oct 2005 19:45:40 +0200") Message-ID: <87irw199xt.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Jim Meyering writes: > Are there `real' environments that use a set-up like you describe, > with a writable file system mounted inside a read-only one? I vaguely recall doing this myself a while back, on a Solaris box. I made /usr read-only, but /usr/tmp was a writeable filesystem under /usr. I expect that others might do this sort of thing too -- with NFS mounts on diskless systems, say. > 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. I looked into the POSIX spec for mkdir(2), and it allows mkdir to return whatever error code it likes when more than one error code applies. So, for example, if /usr is not writeable and /usr/bin exists, then mkdir("/usr/bin", 0) is allowed to fail with errno==EACCES. My interpretation is that Cygwin is within its POSIX rights to fail with errno==EROFS here. Admittedly this is a bit weird, but it's not that hard to make the coreutils code accommodate the POSIX-allowed behavior for mkdir(2), and no extra system calls are needed in the usual case (as per my proposed patch in ). Christopher Faylor writes: > I'm just wondering if there is some kind of official coreutils policy > here. Not for coreutils itself, no. However, the GNU coding standards make it clear that porting to systems like Cygwin is lower priority for the GNU project than porting to GNU/Linux. See . That being said, I think the patch mentioned above should do the trick. -- 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/