Date: Mon, 17 Aug 2015 16:19:34 -0700 From: Kirk McKusick <mckusick@mckusick.com> To: John Baldwin <jhb@freebsd.org> Cc: Adrian Chadd <adrian.chadd@gmail.com>, "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, Jilles Tjoelker <jilles@stack.nl> Subject: Re: futimens and utimensat vs birthtime Message-ID: <201508172319.t7HNJYKN018032@chez.mckusick.com> In-Reply-To: <6270978.RcR1JVbHrR@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
> From: John Baldwin <jhb@freebsd.org> > To: Adrian Chadd <adrian.chadd@gmail.com> > Subject: Re: futimens and utimensat vs birthtime > Date: Mon, 17 Aug 2015 15:28:45 -0700 > > On Sunday, August 16, 2015 12:05:07 PM Adrian Chadd wrote: >> .. then make it take a struct and a type flag. :P >> >> Then you can extend it however you'd like. > > I think that might be a bit much (making it a struct), but one option > could be to add an argument that says how many timespecs are in the > array. Any "missing" timespecs could be treated as if they were set > to UTIME_OMIT. This would in theory mean you could support additional > timestamps in the future without needing new calls. I'm just not sure > if there are any conceivable timestamps such that this flexibility is > warranted? I agree that it is unlikely that you would ever need another timestamp. But just to stretch my imagination to think of a conceivable one, how about a "snapshot" timestamp that indicates the time that the snapshot of the file was taken. If it is a log file, that would let you know when events stopped being able to be logged to it. ~Kirk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201508172319.t7HNJYKN018032>