Mail Archives: cygwin/2006/01/26/10:26:08
> > > This is highly unexpected, does not match linux behaviour (it returns
> EEXIST),
> > > and actually breaks git (git clone, creation of pathnames, to be precise).
> >
> > Then git has a bug. Report it there. To be portable
> > when making pathnames, you must first check
> > for directory existance rather than relying on an
> > errno of EEXIST to tell you the directory exists.
>
> How do you do it race-free?
chdir(). If chdir() succeeded, then the directory existed,
regardless of the errno that mkdir() reported.
Take a look at gnulib's mkdir-p.c module:
http://cvs.savannah.gnu.org/viewcvs/gnulib/lib/mkdir-p.c?rev=1.5&root=gnulib&view=auto
>
> No, I don't think it is a bug in git, or in any code which
> expects EEXIST from mkdir in case an entry actually
> just plain does exist.
POSIX does not guarantee EEXIST when calling mkdir()
on an existant directory. Get used to that - any code
that assumes that mkdir MUST fail with EEXIST is
inherently unportable, according to POSIX.
>
> Are you sure? Linux 2.6.15. It correctly reports EEXIST
> on /usr and /usr/local and creates /usr/local/dir.
> I'd consider that a bug, if it were otherwise. The reason
> of racing alone if enough.
Maybe the setup was slightly different than I remembered,
Paul Eggert described it here:
http://lists.gnu.org/archive/html/bug-coreutils/2005-10/msg00155.html
In fact, that entire thread is where this mkdir not failing
with EEXIST issue came up.
--
Eric Blake
--
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/
- Raw text -