From owner-freebsd-fs@freebsd.org Mon Nov 9 03:16:32 2015 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 E786BA29CCF for ; Mon, 9 Nov 2015 03:16:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B6EC5153F; Mon, 9 Nov 2015 03:16:31 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-78.lns20.per1.internode.on.net [121.45.229.78]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id tA93GNhD079306 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 8 Nov 2015 19:16:26 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: futimens and utimensat vs birthtime (resurected) To: Kirk McKusick References: <201508142122.t7ELMPjR002452@chez.mckusick.com> Cc: "freebsd-fs@freebsd.org" , "'Jilles Tjoelker'" , John Baldwin From: Julian Elischer Message-ID: <56401002.8020909@freebsd.org> Date: Mon, 9 Nov 2015 11:16:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <201508142122.t7ELMPjR002452@chez.mckusick.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 03:16:32 -0000 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). >> >> -- >> John Baldwin > 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) the syscall name is also not decided. one suggested form is: $name (int fd, int32 flags/mask, const struct timespec *arrayptr[]); vs the current: utimensat(int fd, const char *path, const struct timespec times[2], int flag); where mask is: --- 0x01 disable_heuristic 0x02 AT_SYMLINK_NOFOLLOW 0x04-0x08 unused -- times present--- 0x10 access time 0x20 mod time 0x40 birth time 0x80 archive time 0x100 conception time 0x200-on reserverd for future times any bit not set in 0x010-on is not represented in the array. no bits would be a nop (the price for orthogonality) and would effectively be the same as a test for writeability. "disable heuristic" would disable the forcing of birthtime back to mod time or earlier (and any other 'logical fixes') setting all 5 'time-present' bits would imply the array has 5 entries. anyone care to comment > > Kirk McKusick >