Mail Archives: cygwin/2005/10/12/14:17:52
On Wed, Oct 12, 2005 at 07:45:40PM +0200, Jim Meyering wrote:
>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,
mkdir() doesn't use lstat. The right way to fix this within cygwin
means modifying some lower level path code.
>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.
I am curious about the criteria that you use for accommodating the
quirks of the operating systems that coreutils supports, however.
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.
If this was an issue with Linux would you be advocating changing Linux?
Would you be comfortable with a version of coreutils for Linux that only
works with, e.g., 2.6.13 and nothing else?
I'm just wondering if there is some kind of official coreutils policy
here.
cgf
--
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/
- Raw text -