Package: manpages-dev
Version: 3.27-1
Severity: minor
Tags: upstream
Justification: http://bugs.debian.org/620679
Hi,
The lutimes(3) manpage explains:
Errors are as for utimes(2), with the following additions for
futimes():
EBADF fd is not a valid file descriptor.
ENOSYS The /proc file system could not be accessed.
where for reference, the list of errors in utimes(2) is below[1]. But
it never mentions a certain, more common error:
ENOSYS (Linux: the kernel version is below 2.6.22.)
Assuming I can trust utimensat(2), it might also be good to mention
EACCES times is NULL, and the file is marked immutable (see
chattr(1).
EFAULT times points to an invalid address, or filename is
NULL or an invalid address
EINVAL invalid value in one of the tv_nsec fields (see
utimensat(2)), or an invalid value in one of the
tv_sec fields
ELOOP too many symbolic links were encountered in resolving
filename
ENAMETOOLONG filename is too long
ENOENT a component of filename does not refer to an existing
directory or file, or filename is an empty string
ENOTDIR one of the prefix components of filename is not a
directory
EPERM attempting to change a time but the file is marked
append-only (see chattr(1))
ESRCH search permission is denied for one of the prefix
components of filename
though I'm not sure such detail is warranted --- maybe
path_resolution.7 could mention the errors it can produce, and
the error section in utimensat.2 and futimes.3 could just say
something like
EACCES, ESRCH, ENAMETOOLONG, ENOTDIR, ELOOP
see path_resolution(7)
to cover that part.
Hope that helps.
[1]
EACCES Search permission is denied for one of the directories
in the path prefix of path (see also path_resolution(7)).
EACCES times is NULL, the caller's effective user ID does not
match the owner of the file, the caller does not have
write access to the file, and the caller is not
privileged (Linux: does not have either the
CAP_DAC_OVERRIDE or the CAP_FOWNER capability).
ENOENT filename does not exist.
EPERM times is not NULL, the caller's effective UID does not
match the owner of the file, and the caller is not
privileged (Linux: does not have the CAP_FOWNER
capability).
EROFS path resides on a read-only file system.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
