Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 10 Sep 2002 04:40:03 -0700 (PDT)
From:      Bruce Evans <bde@zeta.org.au>
To:        freebsd-bugs@FreeBSD.org
Subject:   Re: kern/42617: rename(2) IEEE Std 1003.1-2001 Violation
Message-ID:  <200209101140.g8ABe3sD026257@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/42617; it has been noted by GNATS.

From: Bruce Evans <bde@zeta.org.au>
To: David Malone <dwmalone@maths.tcd.ie>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/42617: rename(2) IEEE Std 1003.1-2001 Violation
Date: Tue, 10 Sep 2002 21:38:57 +1000 (EST)

 On Tue, 10 Sep 2002, David Malone wrote:
 
 >  On Tue, Sep 10, 2002 at 02:59:34AM +0200, Matthias Andree wrote:
 >  > When using rename with old and new path referring to the same file (through
 >  > hard links), old path is removed. This is a violation of IEEE Std 1003.1-2001.
 >  > This is also a violation of the Single Unix Specification 2. Either demands
 >  > that if the old argument and the new argument point to the same existing file,
 >  > rename() shall do nothing and return success.
 >
 >  Doing nothing and returning success would seem to be inconsistent
 >  with C99:
 >
 >  	The rename function causes the file whose name is the string
 >  	pointed to by old to be henceforth known by the name given by
 >  	the string pointed to by new. The file named old is no longer
 >  	accessable by that name.
 
 This seems to be a bug in C90, since I think it stole rename() from
 POSIX and POSIX has always clearly specified that at least
 rename("x", "x") return successfully and perform no other action.  The
 C standard requires an error for this case since making "x" inaccessible
 would be more surprising.
 
 >  Mind you, it does say that if the new file exists before prior to
 >  the rename call, then the behaviour is implimentation defined. What
 >  does the wording in IEEE Std 1003.1-2001 look like?
 
 Better look at the whole standard since it is not very consistent and
 support for different interpretations is too easy to provide by not
 quoting everything relevant.  My fix for this PR paraphrases small parts
 of it :-).
 
 Bruce
 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209101140.g8ABe3sD026257>