Bug 26022
| Summary: | futimesat and utimensat handle NULL filenames | ||
|---|---|---|---|
| Product: | Documentation | Reporter: | Mike Frysinger (vapier) |
| Component: | man-pages | Assignee: | documentation_man-pages (documentation_man-pages) |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | mtk.manpages |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
Mike, The utimensat() behavior is discussed under NOTES in its man page. The futimesat() behavior is discssed under NOTES in its man page. So, I'm closing as invalid. If you think something is still missing, please reopen and let me know what it is.. |
if you pass futimesat or utimensat a NULL path, the functions will operate on the fd as given. in which case it can be either a fd for a directory or a file. for example, the two calls to futimesat() below will do the same thing: #include <fcntl.h> #include <stdio.h> int main() { int fd = open("f", O_CREAT|O_RDWR, 0777); printf("futimesat = %i\n", futimesat(fd, NULL, NULL)); printf("futimesat = %i\n", futimesat(AT_FDCWD, "f", NULL)); return 0; } same behavior can be observed with utimensat(), but it seems only at the Linux syscall level. the POSIX/C library level will reject a NULL filename with errno==EINVAL, but the Linux kernel will treat the dirfd as an fd. funny enough, while glibc rejects pathname==NULL at its ABI, it relies on the Linux ABI to accept pathname==NULL while implementing other functions.