Hi, While researching libc++ test failures, I've discovered that NetBSD suffers from the same issue as FreeBSD -- that is, both the userspace tooling and the kernel have problems with (time_t)-1 timestamp, i.e. one second before the epoch. For example: $ TZ=UTC touch -t 196912312359.59 test touch: out of range or illegal time specification: [[CC]YY]MMDDhhmm[.SS] The problem is that -1 is being used as a special value (error return here) while it is also a technically valid time_t value. While I don't think this is a major issue, I feel it's a bad design to exclude a single-second period in the middle of allowed time range. The particular issue in touch(1) is easy to fix -- I can set 'errno = 0' before mktime() value, and add a check for non-zero errno to verify whether -1 indicates an error or just happens to be the return value. Sadly, this does not solve the problem entirely since kernel also special-cases the value of '-1'. FWICS, the vattr structure used to update filesystem information uses the value of VNOVAL or -1 to indicate that the particular attribute should not be changed. As a result, any attempt to set a timestamp with tv_sec=-1 is silently ignored by the kernel. I can think of a few possible ways out of this: a. Use a different tv_sec value to indicate 'no change', e.g. largest negative integer. This doesn't exactly solve all the problems but moves it to the edge of allowed range rather than in the middle of it. b. Use out-of-range tv_nsec values to indicate 'no change', like utimensat() does. c. Add an extra flag to va_vaflags that explicitly indicates timestamps are supposed to be changed; always ignore tv_sec when it's unset, otherwise respect tv_sec independently of value. What do you think? -- Best regards, Michał Górny
Attachment:
signature.asc
Description: This is a digitally signed message part