unlink(2) [osx man page]
UNLINK(2) BSD System Calls Manual UNLINK(2) NAME
unlink -- remove directory entry SYNOPSIS
#include <unistd.h> int unlink(const char *path); DESCRIPTION
The unlink() function removes the link named by path from its directory and decrements the link count of the file which was referenced by the link. If that decrement reduces the link count of the file to zero, and no process has the file open, then all resources associated with the file are reclaimed. If one or more process have the file open when the last link is removed, the link is removed, but the removal of the file is delayed until all references to it have been closed. RETURN VALUES
Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. ERRORS
The unlink() system call will fail if: [EACCES] Search permission is denied for a component of the path prefix. [EACCES] Write permission is denied on the directory containing the link to be removed. [EBUSY] The entry to be unlinked is the mount point for a mounted file system. [EBUSY] The file named by the path argument cannot be unlinked because it is being used by the system or by another process. [EFAULT] Path points outside the process's allocated address space. [EIO] An I/O error occurs while deleting the directory entry or deallocating the inode. [ELOOP] Too many symbolic links are encountered in translating the pathname. This is taken to be indicative of a looping symbolic link. [ENAMETOOLONG] A component of a pathname exceeds {NAME_MAX} characters, or an entire path name exceeds {PATH_MAX} characters (possibly as a result of expanding a symlink). [ENOENT] The named file does not exist. [ENOTDIR] A component of the path prefix is not a directory. [EPERM] The named file is a directory and the effective user ID of the process is not the super-user. [EPERM] The directory containing the file is marked sticky, and neither the containing directory nor the file to be removed are owned by the effective user ID. [EROFS] The named file resides on a read-only file system. SEE ALSO
close(2), link(2), rmdir(2), symlink(7) HISTORY
An unlink() function call appeared in Version 6 AT&T UNIX. 4th Berkeley Distribution June 4, 1993 4th Berkeley Distribution
Check Out this Related Man Page
UNLINK(2) BSD System Calls Manual UNLINK(2) NAME
unlink, unlinkat -- remove directory entry SYNOPSIS
#include <unistd.h> int unlink(const char *path); int unlinkat(int fd, const char *path, int flag); DESCRIPTION
The unlink() function removes the link named by path from its directory and decrements the link count of the file which was referenced by the link. If that decrement reduces the link count of the file to zero, and no process has the file open, then all resources associated with the file are reclaimed. If one or more process have the file open when the last link is removed, the link is removed, but the removal of the file is delayed until all references to it have been closed. The unlinkat() system call is equivalent to unlink() or rmdir() except in the case where path specifies a relative path. In this case the directory entry to be removed is determined relative to the directory associated with the file descriptor fd instead of the current working directory. The values for flag are constructed by a bitwise-inclusive OR of flags from the following list, defined in <fcntl.h>: AT_REMOVEDIR Remove the directory entry specified by fd and path as a directory, not a normal file. If unlinkat() is passed the special value AT_FDCWD in the fd parameter, the current working directory is used and the behavior is identical to a call to unlink or rmdir respectively, depending on whether or not the AT_REMOVEDIR bit is set in flag. RETURN VALUES
Upon successful completion, a value of 0 is returned. Otherwise, a value of -1 is returned and errno is set to indicate the error. ERRORS
The unlink() system call will fail if: [EACCES] Search permission is denied for a component of the path prefix. [EACCES] Write permission is denied on the directory containing the link to be removed. [EBUSY] The entry to be unlinked is the mount point for a mounted file system. [EBUSY] The file named by the path argument cannot be unlinked because it is being used by the system or by another process. [EFAULT] Path points outside the process's allocated address space. [EIO] An I/O error occurs while deleting the directory entry or deallocating the inode. [ELOOP] Too many symbolic links are encountered in translating the pathname. This is taken to be indicative of a looping symbolic link. [ENAMETOOLONG] A component of a pathname exceeds {NAME_MAX} characters, or an entire path name exceeds {PATH_MAX} characters (possibly as a result of expanding a symlink). [ENOENT] The named file does not exist. [ENOTDIR] A component of the path prefix is not a directory. [EPERM] The named file is a directory and the effective user ID of the process is not the super-user. [EPERM] The directory containing the file is marked sticky, and neither the containing directory nor the file to be removed are owned by the effective user ID. [EROFS] The named file resides on a read-only file system. In addition to the errors returned by the unlink(), the unlinkat() may fail if: [EBADF] The path argument does not specify an absolute path and the fd argument is neither AT_FDCWD nor a valid file descriptor open for searching. [ENOTEMPTY] The flag parameter has the AT_REMOVEDIR bit set and the path argument names a directory that is not an empty directory, or there are hard links to the directory other than dot or a single entry in dot-dot. [ENOTDIR] The flag parameter has the AT_REMOVEDIR bit set and path does not name a directory. [EINVAL] The value of the flag argument is not valid. [ENOTDIR] The path argument is not an absolute path and fd is neither AT_FDCWD nor a file descriptor associated with a directory. SEE ALSO
close(2), link(2), rmdir(2), symlink(7) STANDARDS
The unlinkat() system call is expected to conform to POSIX.1-2008 . HISTORY
An unlink() function call appeared in Version 6 AT&T UNIX. The unlinkat() system call appeared in OS X 10.10 4th Berkeley Distribution June 4, 1993 4th Berkeley Distribution