touch doesn't trigger IN_CLOSE_WRITE on Linux (breaks inotify-based reloaders)

[mattsu2020]

Summary

On Ubuntu Questing (25.10), touch from uutils-coreutils does not trigger IN_CLOSE_WRITE, only IN_ATTRIB. Software that watches files via inotify masks such as IN_CLOSE_WRITE fails to detect modifications. Switching to GNU coreutils immediately fixes the issue.

This breaks 0 A.D. tests that rely on touch to trigger file reload via inotify, causing an infinite loop (ReloadChangedFiles keeps returning SKIPPED).

Repro

1. Watch a file with inotify for IN_CLOSE_WRITE.
2. Run uutils touch <file>.
3. Observe that no IN_CLOSE_WRITE event is emitted (only IN_ATTRIB).

GNU coreutils emits IN_CLOSE_WRITE for the same sequence.

Expected

touch should open the file for write and use futimens (or equivalent) so that IN_CLOSE_WRITE is emitted on Linux (matching GNU touch behavior).

Actual

uutils touch updates timestamps via path-based set_file_times without opening the file, which does not emit IN_CLOSE_WRITE.

Proposed fix

On Unix, open the file with write permissions and call futimens on the fd when updating times for regular files. Fall back to the existing path-based implementation if open/futimens fails or the target is not a regular file. This aligns behavior with GNU touch and triggers IN_CLOSE_WRITE.

Patch (summary)

• In src/uu/touch/src/touch.rs:
  • Attempt OpenOptions::new().write(true).open(path) and libc::futimens(fd, times) on regular files.
  • If successful, return early; otherwise fall back to set_file_times.

related
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2136917