stat(2): expand list of syscalls that modify st_mtim

[asomers]

Summary

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.

[kib]

I do not understand this change. Are you claiming that link(2) modifies mtim ? If yes, for which vnode ?

[asomers]

In D18410#391986, @kib wrote:

I do not understand this change. Are you claiming that link(2) modifies mtim ? If yes, for which vnode ?

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.

[asomers]

Also note that mknod does not update atime

[kib]

In D18410#392016, @asomers wrote:

In D18410#391986, @kib wrote:

I do not understand this change. Are you claiming that link(2) modifies mtim ? If yes, for which vnode ?

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.

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.

[asomers]

Leave syscall list open-ended.

[asomers]

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?

[kib]

lib/libc/sys/stat.2

211 ↗

(On Diff #51532)

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 ,
...

218 ↗

(On Diff #51532)

Not 'parent'.

223 ↗

(On Diff #51532)

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.

[asomers]

lib/libc/sys/stat.2

223 ↗

(On Diff #51532)

Actually, it does. I verified that both write and pwrite do update ctime even if file size is unchanged, on both UFS and ZFS.

[asomers]

Use kib's preferred wording for directory-updating syscalls.

[kib]

lib/libc/sys/stat.2

223 ↗

(On Diff #51532)

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'.

[asomers]

Clarify why write(2) updates st_ctim