From owner-freebsd-current@freebsd.org Mon Aug 17 05:26:01 2015 Return-Path: Delivered-To: freebsd-current@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 954539B7F53; Mon, 17 Aug 2015 05:26:01 +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 CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 53BDF1AC4; Mon, 17 Aug 2015 05:26:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-240-35.lns20.per4.internode.on.net [121.45.240.35]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id t7H5Pri8025838 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 16 Aug 2015 22:25:56 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: futimens and utimensat vs birthtime To: Jilles Tjoelker References: <55CDFF32.7050601@freebsd.org> <2405496.WdPSxGzEuT@ralph.baldwin.cx> <55D09D8D.7010206@freebsd.org> <20150816214616.GA38422@stack.nl> Cc: John Baldwin , freebsd-current@freebsd.org, "freebsd-fs@freebsd.org" From: Julian Elischer Message-ID: <55D1705C.7070305@freebsd.org> Date: Mon, 17 Aug 2015 13:25:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150816214616.GA38422@stack.nl> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 05:26:01 -0000 On 8/17/15 5:46 AM, Jilles Tjoelker wrote: > On Sun, Aug 16, 2015 at 10:26:21PM +0800, Julian Elischer wrote: >> On 8/15/15 1:39 AM, John Baldwin wrote: >>> 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. > Using AT_* flags for things unrelated to pathnames is not without > precedent: AT_REMOVEDIR for unlinkat() and AT_EACCESS for faccessat(). > This isn't suitable for a large number of flags, though. > >> I wasn't suggesting we keep the old ones and silently make them take 3 >> args :-) >> I was thining of suplementing them wth new syscalls and the obvious >> names are those you suggested. >> however I do wonder if there will ever be a need for a 4th... > This could be indicated by yet another flag. not in futimens, futimes or any of the other varieties that have no flags.. > > I'm a bit disappointed that setting birthtimes apparently wasn't needed > when I added futimens and utimensat. However, they are not part of any > release yet, so it may be possible to remove them at some point. Well they are defined in posix as only taking the two args right? I'm not sure I am parsing your statement correctly. It reads a bit like you are disappointed at yourself, which doesn't seem right. I think we should keep them as they are part of posix and part of Linux. We actually independently added them at $JOB (for Linux compat) but now we have a need for better birthtime control. In the meantime UFS2 and ZFS both have birthtime and its use is getting more widespread. (not sure if NFSv4 supports it but Samba needs it for full emulation) We'd rather add a new call in conjunction with FreeBSD rather than add our own and see FreeBSD add a slightly different one. It is possible we could do a syscall capable of doing 3, and just have a library entry that is compatible with the standard as a front end. suggestions welcome. >