[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: mkdir -p and EROFS
Re: mkdir -p and EROFS
Wed, 12 Oct 2005 19:45:40 +0200
address@hidden (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
> 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,
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?
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.
That feels too kludgy.