From: khan AT xraylith DOT wisc DOT edu (Mumit Khan)
Subject: Re: incompatible rename in crtdll
31 Oct 1998 12:45:40 -0800
Message-ID: <Pine.SUN.3.93.981030182609.1901C-100000.cygnus.gnu-win32@modi.xraylith.wisc.edu>
References: <3638DC9E DOT 5D11EDEE AT hem2 DOT passagen DOT se>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
To: Anders Norlander <anorland AT hem2 DOT passagen DOT se>
Cc: gnu-win32 AT cygnus DOT com, colin AT fu DOT is DOT saga-u DOT ac DOT jp

On Thu, 29 Oct 1998, Anders Norlander wrote:

> I have noticed that rename in crtdll does not behave as you would
> expect it to do on a unix system. If the new filename already
> exists the function will fail. I noticed this when porting
> patch to mingw32. Cygwin handles this correctly.
> To get around it you would have to do something like this:
> 
> #define rename(f,t) _ming_rename

This is a known bug in every MS runtime (acknowledged by everyone
but MS of course ;-)

This was a bug in a few of the older Unix systems as well, and my 
configure script still checks for this. If I see a buggy OS, *and*
if the OS runtime supports ``unlink'' (non-ANSI, but part of POSIX) 
in some form of the other, I unlink the <target> first. Unfortunately, 
this breaks rename()'s atomicity semantics, and by the same token 
any replacement we provide for mingw will be subtly broken as well.
(I was thinking of providing a modified rename() libmingw32.a at 
one point, but deccided against it because of this reason).

Regards,
Mumit


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".