RENAME(2) System Calls Manual RENAME(2)
rename, renameat - change the name of a file
rename(const char *from, const char *to);
renameat(int fromfd, const char *from, int tofd, const char *to);
The rename() function causes the link named from to be renamed as to. If
to exists, it is first removed. Both from and to must be of the same
type (that is, both directories or both non-directories), and must reside
on the same file system.
rename() guarantees that if to already exists, an instance of to will
always exist, even if the system should crash in the middle of the
If the final component of from is a symbolic link, the symbolic link is
renamed, not the file or directory to which it points.
The renameat() function is equivalent to rename() except that where from
or to specifies a relative path, the directory entry names used are
resolved relative to the directories associated with file descriptors
fromfd or tofd (respectively) instead of the current working directory.
If renameat() is passed the special value AT_FDCWD (defined in <fcntl.h>)
in the fromfd or tofd parameter, the current working directory is used
for resolving the respective from or to argument.
Upon successful completion, the value 0 is returned; otherwise the
value -1 is returned and the global variable errno is set to indicate the
rename() and renameat() will fail and neither of the argument files will
be affected if:
[ENAMETOOLONG] A component of a pathname exceeded NAME_MAX
characters, or an entire pathname (including the
terminating NUL) exceeded PATH_MAX bytes.
[ENOENT] A component of the from path does not exist, or a path
prefix of to does not exist.
[EACCES] A component of either path prefix denies search
[EACCES] The requested change requires writing in a directory
that denies write permission.
[EACCES] The from argument is a directory and denies write
[EPERM] The directory containing from is marked sticky, and
neither the containing directory nor from are owned by
the effective user ID.
[EPERM] The to file exists, the directory containing to is
marked sticky, and neither the containing directory
nor to are owned by the effective user ID.
[ELOOP] Too many symbolic links were encountered in
translating either pathname.
[EMLINK] The link count on the source file or destination
directory is at the maximum. A rename cannot be
completed under these conditions.
[ENOTDIR] A component of either path prefix is not a directory.
[ENOTDIR] from is a directory, but to is not a directory.
[EISDIR] to is a directory, but from is not a directory.
[EXDEV] The link named by to and the file named by from are on
different logical devices (file systems). Note that
this error code will not be returned if the
implementation permits cross-device links.
[ENOSPC] The directory in which the entry for the new name is
being placed cannot be extended because there is no
space left on the file system containing the
[EDQUOT] The directory in which the entry for the new name is
being placed cannot be extended because the user's
quota of disk blocks on the file system containing the
directory has been exhausted.
[EIO] An I/O error occurred while making or updating a
[EROFS] The requested link requires writing in a directory on
a read-only file system.
[EFAULT] from or to points outside the process's allocated
[EINVAL] from is a parent directory of to, or an attempt is
made to rename `.' or `..'.
[ENOTEMPTY] to is a directory and is not empty.
Additionally, renameat() will fail if:
[EBADF] The from or to argument specifies a relative path and
the fromfd or tofd argument, respectively, is neither
AT_FDCWD nor a valid file descriptor.
[ENOTDIR] The from or to argument specifies a relative path and
the fromfd or tofd argument, respectively, is a valid
file descriptor but it does not reference a directory.
[EACCES] The from or to argument specifies a relative path but
search permission is denied for the directory which
the fromfd or tofd file descriptor, respectively,
mv(1), open(2), symlink(7)
The rename() and renameat() functions conform to IEEE Std 1003.1-2008
The renameat() function appeared in OpenBSD 5.0.
The system can deadlock if a loop in the file system graph is present.
This loop takes the form of an entry in directory `a', say `a/foo', being
a hard link to directory `b', and an entry in directory `b', say `b/bar',
being a hard link to directory `a'. When such a loop exists and two
separate processes attempt to perform `rename a/foo b/bar' and `rename
b/bar a/foo', respectively, the system may deadlock attempting to lock
both directories for modification. Hard links to directories should be
replaced by symbolic links by the system administrator.
OpenBSD 5.7 January 19, 2015 OpenBSD 5.7
[Unix Hosting |
[Engineering & Automation |
Software Development |