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>