Defect Report concerning: IEEE Std. 1003.1-1996, ISO/IEC 9945-1:1996 - C API
Clause: 5.5.3.2.
PASC Interpretation Ref: pasc-1003.1-77
Topic: rename


This is an unapproved interpretation of PASC 1003.1-1996, ISO/IEC 9945-1:1996 - C API.

Use of the information contained in this unapproved document is at your own risk.

Last update: 10 April,2001


								1003.1-90  #77

 _____________________________________________________________________________

	Interpretation Number:	77
	Topic:               rename
	Relevant Sections:   5.5.3.2.

Interpretation Request: (Defect Report)
-----------------------


	Date: Wed, 4 Sep 1996 15:58:08 -0400 (EDT)

(Note line numbers are against 1003.1b-1993, but this is applicable
to 1003.1-90 included in ISO POSIX.1-1996)

The standard states:

		If the old argument and the new argument both refer
		to links to the same existing file, the rename()
		function shall return successfully and perform no
		other action.


Question:

	I am assuming that the rationale for the above clause was to ensure
	that rename("x", "x") does not remove the file "x".  I based my
	assumption on the rationale in subsection B.5.5.3 (lines 3625 through
	3628).  I feel that the above clause is too restrictive.

	If you have two files "x" and "y" that both refer to links to the
	same existing file, then rename("x", "y") will return successfully
	and perform no other action.  I think if would be more logical to
	perform a remove of link "x" in this situation.

	This implementation of rename() would result in the following
	behaviour from the shell prompt (assuming the mv utility is
	compliant with IEEE Std 1003.2-1992 4.43.2 lines 7095 to 7103):

		$ touch x 
		$ ln x y 
		$ ls -li x y 
		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 x 
		186625 -rw-r--r--  2 kirk  techies  0 Aug 23 10:43 y 
		$ mv x y 
		$ ls -li y 
		186625 -rw-r--r--  1 kirk  techies  0 Aug 23 10:43 y 


	But this implementation may fail some PCTS, since the test suite
	may look at only "inode numbers" to determine if the "x" and "y"
	are links to the same existing file and therefore would expect no
	action to be performed.

	The "4.4BSD Lite" distribution appears to support this
	implementation.  Since rename() was first implemented in 4.xBSD,
	I found it strange that the 4.4BSD implementation of rename()
	would not pass a PCTS. I used the following files a reference:

		/usr/src/sys/ufs/ufs/ufs_vnops.c
		/usr/src/sys/kern/vfs_syscalls.c


Suggested Correction:

	The clause should be changed to:

		If the old argument and the new argument both refer to
		a file with the same name in the same directory, the
		rename() function shall return successfully and perform
		no other action.



Interpretation response
------------------------
The standard clearly states the requirements for rename(), and conforming 
implementations must conform to this.


Rationale
-------------
Interpretations must be a comment on what
the standard actually does say, not what it should say, nor 
what it says incorrectly. Changes to the standard may be submitted
through the revisions process.

Forwarded to Interpretations group: Sep 8 1996
Forwarded for review: Oct 22 1996
Finalised: Nov 24 1996