unlinkat (GNU Gnulib)

Gnulib module: unlinkat

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, 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 <fcntl.h>, not in <unistd.h>, on some platforms: Cygwin 1.7.1, Android 4.3.
On Mac OS X 10.10, in a writable HFS mount, unlinkat(fd, "..", 0) succeeds without doing anything.
Some systems mistakenly succeed on unlinkat(fd,"file/",flag): GNU/Hurd, Solaris 9.

Portability problems not fixed by Gnulib:

When unlinkat(fd,name,AT_REMOVEDIR) fails because the specified directory is not empty, the errno value is system dependent.
POSIX requires that unlinkdir(fd,"link-to-empty/",AT_REMOVEDIR) remove empty and leave link-to-empty as a dangling symlink. This is counter-intuitive, so some systems fail with ENOTDIR instead: glibc
Some systems allow a superuser to unlink directories, even though this can cause file system corruption. The error given if a process is not permitted to unlink directories varies across implementations; it is not always the POSIX value of EPERM. Meanwhile, if a process has the ability to unlink directories, POSIX requires that unlinkat(fd,"symlink-to-dir/",0) remove dir and leave symlink-to-dir dangling; this behavior is counter-intuitive. The gnulib module unlinkdir can help determine whether code must be cautious of unlinking directories.
Removing an open file is non-portable: On Unix this allows the programs that have the file already open to continue working with it; the file’s storage is only freed when the no process has the file open any more. On Windows, the attempt to remove an open file fails.