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, 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
<fcntl.h>, not in
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
GNU/Hurd, Solaris 9.
Portability problems not fixed by Gnulib:
unlinkat(fd,name,AT_REMOVEDIR) fails because the specified
directory is not empty, the
errno value is system dependent.
- POSIX requires that
remove empty and leave link-to-empty as a dangling
symlink. This is counter-intuitive, so some systems fail with
- 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.