stat(2): expand list of syscalls that modify st_mtim
creat, link, rename, rmdir, symlink, truncate, and unlink all modify st_mtim
as well as st_ctim. Verified on UFS and ZFS.
Details
Details
- Reviewers
kib - Group Reviewers
manpages - Commits
- rS345391: MFC r340455, r340525, r341598
rS344134: MFC r341598:
rS341598: stat(2): clarify which syscalls modify file timestamps
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 21331 Build 20661: arc lint + arc unit
Event Timeline
Comment Actions
I do not understand this change. Are you claiming that link(2) modifies mtim ? If yes, for which vnode ?
Comment Actions
Yes. link(2) and every other syscall that creates a new file, like mkdir(2), mkfifo(2), creat(2), etc modify the ctime and mtime of the parent directory. Also, I should remove mknod(2) from the list of syscalls that modify atime.
Comment Actions
Ok then, in the current form the patch is not correct. For link(2), we have two vnodes, the one which gets additional name, and the directory where the name is placed. The patch makes the confusion between them.
One option to make the patch correct is to add a new list with enumeration of syscalls which change mtime of the directories participating in the operation (so e.g. creat(2) would be listed twice, one time for the created vnode, and another for the directory where the link to the created vnode is placed).
Another option is to just note that all syscalls that modify directories update its mtime. This seems much more maintainable, because we do add new syscalls, so the list becomes stale fast. Also, I think you would need to list from 1/4 to 1/3 of all syscalls to make the list complete to start from.
Also, for ordinary file accesses, the page fails to mention modifications of the writeable memory mappings of the files.
Comment Actions
Also, for ordinary file accesses, the page fails to mention modifications of the writeable memory mappings of the files.
What wording would you like for that?
| lib/libc/sys/stat.2 | ||
|---|---|---|
| 211 | This is too loose and really unusal formulation. You might say something like Any syscall which modifies directory content changes st_mtim for the affected directory. For instance, .Xr creat 2 , .Xr mknod 2 , ... | |
| 220 | Not 'parent'. | |
| 222 | ctim is only updated when metadata is changed, not data. So for instance, write(2) does not cause update to ctime if file size and file mode are unchanged. | |
| lib/libc/sys/stat.2 | ||
|---|---|---|
| 222 | Actually, it does. I verified that both write and pwrite do update ctime even if file size is unchanged, on both UFS and ZFS. | |
| lib/libc/sys/stat.2 | ||
|---|---|---|
| 222 | In fact yes, I checked UFS and tmpfs. I can see a reasoning there, mtime needs to be updated, but this changes inode content, which implies ctime change. So might be mention this and then there is no need to say 'affects file data or metadata'. | |