[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mkdir -p and EROFS
Re: mkdir -p and EROFS
Thu, 13 Oct 2005 09:35:36 +0200
Christopher Faylor <address@hidden> wrote:
>>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,
> mkdir() doesn't use lstat. The right way to fix this within cygwin
> means modifying some lower level path code.
So it'd be disruptive?
Since Eric Blake mentioned that the rationale for not making the
EROFS->EEXIST change was performance, I was suggesting that the
cost (in decreased efficiency) might be small, and incurred only
in an error case.
>>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?
> We are close to a Cygwin 1.5.19 release and I would rather not add a
> potentially destabilizing change to the cygwin path code at this point.
> I'm not against reevaluating this after 1.5.19 is released.
Ahh... no one mentioned pre-release stability as a reason for not
making the change. That's perfectly reasonable. I can relate :-)
> I am curious about the criteria that you use for accommodating the
> quirks of the operating systems that coreutils supports, however.
If you've followed coreutils development at all, you know that I'm
ready to jump through hoops to work around many types of OS bugs.
But Cygwin is a little different from e.g., Solaris, in that we assume
we need to support versions from only 1 or maybe 2 years back, and even
then, I've heard that it's relatively easy to tell people `upgrade'.
We've done the same with some Linux bugs, too. I know there's at
least one relating to a buggy linux-2.6.x sleep(2) implementation,
but Linux was fixed shortly thereafter.
> Right now, Cygwin does work the way that Eric describes. If we changed
> Cygwin to behave differently that would mean that there would be a
> version of coreutils which would only work in newer Cygwins.
Why not, if the conditions that provoke the bug are as obscure as this
(writable mount in a mounted-read-only tree). Coreutils has required
fchdir for a couple of years now, and older versions of Cygwin lack
that function. But the point is moot, since Paul found a clean way
to work around the problem.
> If this was an issue with Linux would you be advocating changing Linux?
If Linux did what looked like the wrong thing, and was different
from every other system, then yes.