Jim Meyering <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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.
--
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/
