Subject: Re: cygwin-1.5.19-2: mkdir returns inconsistent errno
From: Alex Riesen <[email-masked]>
To: Eric Blake <[email-masked]>
Cc: [email-masked]
Date: Sat, 28 Jan 2006 13:06:37 +0100

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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/