rename() function has the following prototype.
If the file referenced by
new exists prior to calling
rename(), the behavior is implementation-defined. For portability, you must ensure that the file referenced by
new does not exist when
rename() is invoked.
Non-Compliant Code Example
In this non-compliant code example, a file is moved using
If the file named by
new exists at the time of the call to
rename(), the result is implementation-defined.
This compliant solution checks for the existence of the new file before callling
rename(). This code contains an unavoidable race condition between the call to
fopen() and the call to
rename(). Consequently, this code can only be safely executed within a secure directory.
fopen() may fail on many file systems when the file exists but the program does not have sufficient permissions to read it.
Compliant Solution (POSIX)
A somewhat better solution involves using the POSIX
access() function which can check for the existence of a file explicitly [[Open Group 04]]. As with the
fopen() solution, this code contains an unavoidable race condition and consequently can only be safely executed within a secure directory. In fact the existence check is not really needed on POSIX systems, because POSIX specifies the behavior of
rename() when the file referenced by
While the likelihood of
access() returning a false negative is lower than that of
fopen(), on file systems where the program does not have sufficient permissions in the directory to view the file,
access() may return
-1 even when the file exists. In such cases,
rename() will also fail since the program does not have adequate permissions inside the directory.
Compliant Solution (Windows)
_access_s() allows one to check for the existence of a file [[MSDN]]. As with the
fopen() solution, this code contains an unavoidable race condition and consequently can only be safely executed within a secure directory.
_access_s() example shares many of the same problems as the POSIX
access() example above.
rename() has implementation-defined behavior when the new file name refers to an existing file. Incorrect use of
rename() can result in a file being unexpectedly overwritten or other unexpected behavior.
Search for vulnerabilities resulting from the violation of this rule on the CERT website.