Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Jun 2016 11:55:53 -0700
From:      John Baldwin <jhb@freebsd.org>
To:        Julian Elischer <julian@freebsd.org>
Cc:        Kirk McKusick <mckusick@mckusick.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, 'Jilles Tjoelker' <jilles@stack.nl>
Subject:   Re: futimens and utimensat vs birthtime (resurrected)
Message-ID:  <2931129.2EFevmTKZu@ralph.baldwin.cx>
In-Reply-To: <f886e8c7-fb0a-0881-a378-8ad7459ec9a2@freebsd.org>
References:  <201508142122.t7ELMPjR002452@chez.mckusick.com> <56401002.8020909@freebsd.org> <f886e8c7-fb0a-0881-a378-8ad7459ec9a2@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 22, 2016 01:18:22 AM Julian Elischer wrote:
> bringing this up again.
> 
> see below for new info..
> 
> On 9/11/2015 11:16 AM, Julian Elischer wrote:
> > On 8/15/15 5:22 AM, Kirk McKusick wrote:
> >>> From: John Baldwin <jhb@freebsd.org>
> >>> To: freebsd-current@freebsd.org
> >>> Subject: Re: futimens and utimensat vs birthtime
> >>> Date: Fri, 14 Aug 2015 10:39:41 -0700
> >>> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>,
> >>>          "'Jilles Tjoelker'" <jilles@stack.nl>
> >>>
> >>> 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).
> >>>
> >> I concur with John's suggestion. Add a new system call with three
> >> argument set of times specifying birthtime as the last one. I
> >> proposed doing this when I added birthtime, but did not as the
> >> sentiment at the time was that it would gratuitously make FreeBSD
> >> written applications less portable if they used this new non-standard
> >> system call.
> >
> > time has passed and I would like to get back to this:
> > There was some feedback last time. Taking that into account:
> >
> > One problem with the '3 arg' version is that we have to reinvent it 
> > again if we get a 4th.
> > We could make something like the following:
> >
> > It has been suggested that a 4th entry might be "last archive time" 
> > and that
> > "time created on this filesystem" and "file created first time 
> > (ever)" might also
> > be separate in some systems. (as examples of why 3 might not be enough)
> 
> ok, so a real 4th arg has turned up
> 
> it turns out that to be really compatible with windows servers
> and if you are running a filesystem capable of doing it..
> then you need to be able to stamp the "change time".
> 
> Apparently Windows does this an there are applications that require it.
> I believe that most filesystems would simply not do this but at $JOB 
> we have our own FS and it CAN do this.
> we just need a way to interface to it.
> So now we have 4 real and a hypothetical timestamps.
> access time
> modification time
> birth/creation time
> change time
> (archive time)

I think the bitmask thing is perhaps complex, and posix already
prefers to handle "sparse" timespec arrays via UTIME_OMIT.  I would
suggest adding a 'count' argument that specifies the number of items
in the array.  Callers can use UTIME_OMIT for items in the array they
do not wish to set.  I think having some helper macros might be nice
for the array indicies if that doesn't hose the namespace too badly
(UTIME_ACCESS, UTIME_CHANGE, UTIME_MODIFY, UTIME_BIRTH, UTIME_MAX, etc.).

You could then do something like:

	struct timespec ts[UTIME_MAX];

	for (i = 0; i < UTIME_MAX; i++)
		ts[i].tv_nsec = UTIME_OMIT;
#ifdef UTIME_BIRTH
	ts[UTIME_BIRTH] = foo;
#endif
	if (utimensat5(fd, path, ts, count, 0) < 0)
		err(...);

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2931129.2EFevmTKZu>