bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mkdir -p and EROFS


From: Paul Eggert
Subject: Re: mkdir -p and EROFS
Date: Thu, 13 Oct 2005 00:02:06 -0700
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Jim Meyering <address@hidden> 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
<http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00149.html>).


Christopher Faylor <address@hidden> 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
<http://www.gnu.org/prep/standards/html_node/System-Portability.html>.

That being said, I think the patch mentioned above should do the trick.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]