write access to various times

[mdf at FreeBSD.org]

On Fri, Nov 4, 2011 at 11:46 PM, Ronald F. Guilmette
<rfg at tristatelogic.com> wrote:
> It would appear that in 8.2-RELEASE, at least, each "struct stat" contains
> four fields, each of type "timespec", and having the following names:
>
>    st_atimespec
>    st_mtimespec
>    st_ctimespec
>    st_birthtimespec
>
> I already know that if I want to modify either (or both) of the first
> two fields listed above, I should call utimes(2).  But what do I do if I need
> to modify the values of either or both of the other two fields?  (I may want
> to do this, e.g. if I am trying to restore all of the struct stat fields
> from a backed-up representation of some original filesystem entry.)
>
> The current man page for utimes(2) says (among other things):
>
> ===========================================================================
>     ...
>     If times is non-NULL, it is assumed to point to an array of two timeval
>     structures.  The access time is set to the value of the first element,
>     and the modification time is set to the value of the second element.  For
>     file systems that support file birth (creation) times (such as UFS2), the
>     birth time will be set to the value of the second element if the second
>     element is older than the currently set birth time.  To set both a birth
>     time and a modification time, two calls are required; the first to set
>     the birth time and the second to set the (presumably newer) modification
>     time.  Ideally a new system call will be added that allows the setting of
>     all three times at once...
> ===========================================================================
>
> Is there any ETA for this postulated new system call?

To my knowledge, no.  I think this was a hopeful statement on the
original author's part.  AFAIK no one is working on this change.

We have a patch at $WORK that adds a vtimes(2) syscall with support
for setting birthtime as well as mtime and atime.  Some day [1] I may
be able to upstream this functionality back to FreeBSD.

[1] predicated on continued employment, change of roles at $WORK,
time, and community acceptance of the changes.  A rough estimate would
be sometime in the middle or end of 2012.

Cheers,
matthew

> Also, of course, although the method described above for setting the value of
> the st_birthtimespec field is rather clumsey and inefficient, at least there
> _is_ a way to set that field.  I am concerned however because I personally
> still know of no way whatsoever to set the value of the st_ctimespec field.
> Is there any way to do that?
>
> It would be most helpful to have that too.