From owner-freebsd-fs@freebsd.org Tue Jun 21 19:30:43 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E366AC5F24 for ; Tue, 21 Jun 2016 19:30:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D658716F4; Tue, 21 Jun 2016 19:30:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 9C3EAB9A1; Tue, 21 Jun 2016 15:30:41 -0400 (EDT) From: John Baldwin To: Julian Elischer Cc: Kirk McKusick , "freebsd-fs@freebsd.org" , 'Jilles Tjoelker' Subject: Re: futimens and utimensat vs birthtime (resurrected) Date: Tue, 21 Jun 2016 11:55:53 -0700 Message-ID: <2931129.2EFevmTKZu@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <201508142122.t7ELMPjR002452@chez.mckusick.com> <56401002.8020909@freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jun 2016 15:30:41 -0400 (EDT) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 19:30:43 -0000 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 > >>> 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" , > >>> "'Jilles Tjoelker'" > >>> > >>> 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