renameat (GNU Gnulib)

Gnulib module: renameat

Portability problems fixed by Gnulib:

This function is missing on some platforms: glibc 2.3.6, Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, Minix 3.1.8, AIX 5.1, HP-UX 11, IRIX 6.5, Cygwin 1.5.x, mingw, MSVC 14. But the replacement function is not safe to be used in libraries and is not multithread-safe.
This function is declared in <unistd.h>, not in <stdio.h>, on some platforms: NetBSD 7.0, Solaris 11.4.
This function is declared in <sys/stat.h>, not in <stdio.h>, on some platforms: Android 4.3.
This function does not reject trailing slashes on non-directories on some platforms, as in renameat(fd,"file",fd,"new/"): Solaris 11.4.
This function ignores trailing slashes on symlinks on some platforms, such that renameat(fd,"link/",fd,"new") corrupts link: Solaris 9.

Portability problems not fixed by Gnulib:

POSIX requires that renameat(fd,"symlink-to-dir/",fd,"dir2") rename dir and leave symlink-to-dir dangling; likewise, it requires that renameat(fd,"dir",fd,"dangling/") rename dir so that dangling is no longer a dangling symlink. This behavior is counter-intuitive, so on some systems, renameat fails with ENOTDIR if either argument is a symlink with a trailing slash: glibc, OpenBSD, Cygwin 1.7.
POSIX requires that renameat do nothing and return 0 if the source and destination are hard links to the same file. This behavior is counterintuitive, and on some systems renameat is a no-op in this way only if the source and destination identify the same directory entry. On these systems, for example, although renaming ./f to f is a no-op, renaming f to g deletes f when f and g are hard links to the same file: NetBSD 7.0.
After renaming a non-empty directory over an existing empty directory, the old directory name is still visible through the stat function for 30 seconds after the rename, on NFS file systems, on some platforms: Linux 2.6.18.
This function will not rename a source that is currently opened by any process: mingw, MSVC 14.