Re: futimens and utimensat vs birthtime

From: Jilles Tjoelker <jilles_at_stack.nl>
Date: Fri, 14 Aug 2015 22:07:09 +0200
On Fri, Aug 14, 2015 at 10:39:41AM -0700, John Baldwin wrote:
> On Friday, August 14, 2015 10:46:10 PM Julian Elischer wrote:
> > I would like to implement this call. but would like input as to it's 
> > nature.
> > The code inside the system would already appear to support handling 
> > three elements, though it needs some scrutiny,
> > so all that is needed is a system call with the ability to set the 
> > birthtime directly.

> > Whether it should take the form of the existing calls but expecting 
> > three items is up for discussion.
> > Maybe teh addition of a flags argument to specify which items are 
> > present and which to set.

> > ideas?

> I believe these should be new calls.  Only utimensat() provides a flag
> argument, but it is reserved for AT_* flags.  I would be fine with
> something like futimens3() and utimensat3() (where 3 means "three
> timespecs").  Jilles implemented futimens() and utimensat(), so he
> might have ideas as well.  I would probably stick the birth time in
> the third (final) timespec slot to make it easier to update new code
> (you can use an #ifdef just around ts[2] without having to #ifdef the
> entire block).

Without adding new syscalls, it is possible to use the first tv_nsec to
indicate that a new birth time is present. In that case,
times[0].tv_nsec == UTIME_WITHBIRTHTIME would indicate that times has 4
instead of 2 elements.

Whether you want to do this instead of adding two more system calls is a
different question.

Also note that, in some sense, the inability to set the birthtime
forward is a feature.

-- 
Jilles Tjoelker
Received on Fri Aug 14 2015 - 18:07:12 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:59 UTC