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/