This is the mail archive of the
mailing list for the Cygwin project.
Re: cygwin-1.5.19-2: mkdir returns inconsistent errno
Eric Blake, Fri, Jan 27, 2006 23:30:40 +0100:
> According to Alex Riesen on 1/27/2006 11:26 AM:
> > This was a bit prematurely. There is a big problem with this aproach:
> > it changes current directory of the process. So you can't really use
> > it in multithreaded or signalled environment.
> > So chdir is not a real solution. Is it really that hard to workaround
> > the problem in cygwin?
> If the Austin Group API set 2 is approved
> (http://www.opengroup.org/austin/mailarchives/ag/msg08954.html), you will
> have mkdirat() that creates directories relative to an open file
> descriptor on an existing directory; that would alleviate the
> non-threadsafe use of chdir().
I agree completely. It just does not help my original problem
> Until then, I don't know of ANY race-free
> way to create a directory immediately followed by chdir() or open() that
> guarantees that you used the same directory already made by mkdir().
> Maybe if you call mkdir() restricting the access to just the user, then
> open(O_NOFOLLOW), then fchmod(). What would be cool would be something
> like giving valid semantics to open(O_CREAT|O_DIRECTORY) that acts as
> mkdir(), but I doubt that will happen, either, thanks to current Linux
> semantics (http://lkml.org/lkml/2005/9/24/8). Meanwhile, you can always
> spawn mkdir(1) and have another process, with no restrictions on using
> chdir(), do the directory creation for you.
It prohibitively unefficient in my case :(
> If it is really that much of a problem for you, you should consider
> raising a defect against the POSIX standard requesting that mkdir() be
> guaranteed to fail with EEXIST on an existing directory, even if EROFS or
> EACCES or EPERM would also otherwise apply.
Which still wont make a portable alternative any time soon.
I'll go with stat(2), including all the problems it has.
Still, it'd be nice of cygwin to follow linux behaviour here.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html