Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretation for IEEE Std 1003.1™-1990 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)

Copyright © 1998 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department Copyrights and Permissions 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #77
Topic:
rename Relevant Sections: 5.5.3.2.

(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 for Interpretation
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 Finalized: Nov 24 1996