X-Spam-Check-By: sourceware.org
Date: Sat, 28 Jan 2006 13:06:37 +0100
From: Alex Riesen <fork0 AT users DOT sourceforge DOT net>
To: Eric Blake <ebb9 AT byu DOT net>
Cc: cygwin AT cygwin DOT com
Subject: Re: cygwin-1.5.19-2: mkdir returns inconsistent errno
Message-ID: <20060128120637.GA5948@steel.home>
Reply-To: Alex Riesen <fork0 AT users DOT sourceforge DOT net>
References: <012620061525 DOT 1038 DOT 43D8EA05000B44680000040E22007358340A050E040D0C079D0A AT comcast DOT net> <81b0412b0601260821p2a0525dane12307a43e6897f1 AT mail DOT gmail DOT com> <20060127182655 DOT GA6169 AT steel DOT home> <43DA9F10 DOT 8090804 AT byu DOT net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43DA9F10.8090804@byu.net>
User-Agent: Mutt/1.5.6i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/