> Eric Troan wrote:
>
> : I couldn't find a POSIX verdict in ISO 9945-1. All it says is EPERM is
> : returned it the user calling link() doesn't have "appropriate privileges"
> : and that "appropriate privileges" are implementation defined. That doesn't
> : seem to be much help.
This is what the "Single Unix Specification" says. I read this as "if orig
is a file, and you can access(orig), and you can write to the destination
dir, then link(orig,dest) will succeed".
3.12.9 link()
link()
NAME
link ù link to a file
SYNOPSIS
#include <unistd.h>
int link(const char *path1, const char *path2);
DESCRIPTION
The link() function creates a new link (directory entry) for the existing
file, path1.
The path1 argument points to a pathname naming an existing file.
The path2 argument points to a pathname naming the new directory entry to
be created. The link() function will atomically create a new link for the
existing file and the link count of the file is incremented by one.
If path1 names a directory, link() will fail unless the process
has appropriate privileges and the implementation supports using link() on
directories.
Upon successful completion, link() will mark for update the
st_ctime field of the file. Also, the st_ctime and st_mtime fields of the
directory that contains the new entry are marked for update.
If link() fails, no link is created and the link count of the file
will remain unchanged.
The implementation may require that the calling process has
permission to access the existing file.
RETURN VALUE
Upon successful completion, 0 is returned. Otherwise, -1 is returned and
errno is set to indicate the error.
ERRORS
The link() function will fail if:
[EACCES] A component of either path prefix denies search
permission, or the requested link requires writing in a directory with a
mode that denies write permission, or the calling process does not have
permission to access the existing file and this is required by the
implementation.
[EEXIST] The link named by path2 exists.
[ELOOP] UXToo many symbolic links were encountered in resolving
path1 or path2.
[EMLINK] The number of links to the file named by path1
would exceed {LINK_MAX}.
[ENAMETOOLONG]
FIPSThe length of path1 or path2 exceeds {PATH_MAX} or a pathname
component is longer than {NAME_MAX}.
[ENOENT] A component of either path prefix does not exist;
the file named by path1 does not exist; or path1 or path2 points to an
empty string.
[ENOSPC] The directory to contain the link cannot be
extended.
[ENOTDIR] A component of either path prefix is not a
directory.
[EPERM] The file named by path1 is a directory and either the
calling process does not have appropriate privileges or the implementation
prohibits using link() on directories.
[EROFS] The requested link requires writing in a directory on a
read-only file system.
[EXDEV] The link named by path2 and the file named by path1 are on
different file systems and the implementation does not support links
between file systems,
UXor path1 refers to a named STREAM.
The link() function may fail if:
UX[ENAMETOOLONG]
Pathname resolution of a symbolic link produced an intermediate
result whose length exceeds {PATH_MAX}.
APPLICATION USAGE
Some implementations do allow links between file systems.
SEE ALSO
symlink(), unlink(), <unistd.h>.
CHANGE HISTORY
First released in Issue 1.
Derived from Issue 1 of the SVID.
Issue 4
The following change is incorporated for alignment with the ISO POSIX-1
standard:
ò The type of arguments path1 and path2 are changed from
char * to const char *.
The following change is incorporated for alignment with the FIPS
requirements:
ò In the ERRORS section, the condition whereby
[ENAMETOOLONG] will be returned if a pathname component is larger that
{NAME_MAX} is now defined as mandatory and marked as an extension.
Other changes are incorporated as follows:
ò The header <unistd.h> is added to the SYNOPSIS section.
Issue 4, Version 2
The ERRORS section is updated for X/OPEN UNIX conformance as follows:
ò The [ELOOP] error will be returned if too many symbolic
links are encountered during pathname resolution.
ò The [EXDEV] error may also be returned if path1 refers to
a named STREAM.
ò A second [ENAMETOOLONG] condition is defined that may
report excessive length of an intermediate result of pathname resolution
of a symbolic link.
MfG Kai