From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753270AbcEINJ1 (ORCPT ); Mon, 9 May 2016 09:09:27 -0400 Received: from mout.kundenserver.de ([212.227.126.130]:64481 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753132AbcEINJZ (ORCPT ); Mon, 9 May 2016 09:09:25 -0400 From: Arnd Bergmann To: Steve French Cc: David Howells , linux-fsdevel , linux-afs@vger.kernel.org, "linux-nfs@vger.kernel.org" , samba-technical , LKML , "linux-ext4@vger.kernel.org" , Deepa Dinamani Subject: Re: [RFC][PATCH 0/6] Enhanced file stat system call Date: Mon, 09 May 2016 15:09:04 +0200 Message-ID: <4211584.odaTcq8sN6@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:7cOyWhY+g0B9itH506LoV6P8GdR32eQt2q0V5+9yYfwKy8i4sWC f14FSQ8nJb+kA9dGWPRNiUbzEMVkbZVMfIkHaNLwhMWg6aFjnZinvmEBpndi0yr7eACAjH0 MoES82Z4aVnwUytcBJQeo8D+zax5ke+zJ47AGzpVqQvZ1bblJts1oERRUAPewdXEQccGSLE q3L6jUN0NDjCczfNjMt5Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:U454pl8+J8Q=:Wt5xv2PpzlAHFd0F9eMPnY GEA+bsyS59ofJlO2fiRSX5LfPt5BVK+3l07dF0CFaCsoSfVKiZzHz1zF6Xhi1aMpwOdQlxIVI 9l22wbpfI1cYCDccLXgRUyiKZje2+kuIZPdS1Iso8h9mqSrx1x9xHIx8dD5+W0hbEY1QsfbYz j51oqCsnAzKLkaDYaVwd+kNNldPaiE5h7OJ4lKjn+XoYt3mQrkfbkzb9s5X11Qg9ylBhOPhyO hJxpyvBEFjgjQKz1dVPZhCdj98CaYOBJvjFhHkFvd8N5fsou4bnVZ0wL5FvNc8QHJ9CMiVgec KjWFyqzvZQBHhDxNTdeB6ZJoGG85nx/6mBjuDbvSel1lt75XsG5QGrx6tijbnLcRVnzaRiBPg 0ACW7jTwQ0dfiC1PQIvGahihRur7lRSbvBaWXFqi/1ib8v9ksfjTht6b9abpb9ftmyyzAlTqk ZeJMTMfZ6BuZd89sqZZnx51qrSRoX09RVDoPY3yfoqm9Bs9+yyWhyMlZBJEavf5E+UGwCUJK9 bReEvQpPUvmc6A1b6xq2sZ3S9Gl+rc0B8EifeHg7fhL+eH8aJUCW0V3CY/RZC++rj7G9K8Nll SyxaBjAXwfP71Pgv/qE/rEyMc51/6pVI4WKoWoxzf/gDX6TXyL1ACrljp/7O4Fr7DKYybbDF+ obicgJmWrZo58YHiuLGak7NEoAaCUnlSGn4I/B/KUWGtuA03Ou5t2yr6fElwdg5XB+96bFdel 58a79y39pazcoo/j Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thursday 05 May 2016 21:00:18 Steve French wrote: > On Thu, May 5, 2016 at 5:54 PM, Steve French wrote: > > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann wrote: > >> On Friday 29 April 2016 13:57:36 David Howells wrote: > >>> struct statx *buffer); > >>> > >>> This is an enhanced file stat function that provides a number of useful > >>> features, in summary: > >>> > >>> (1) More information: creation time, data version number, inode > >>> generation > >>> number and flags. A subset of these is available through a number of > >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). > >>> > >> > >> I have a question about birthtime/creationtime: As we are gaining a way > >> to read this, should we also provide a way to update it using a new > >> variant > >> of the utimensat syscall in order to have 'cp -a' create an identical > >> copy, > >> or is the idea that this is defined as the time that is particular copy > >> of the inode was created? > >> > >> I've discussed this with Deepa in the past, as she is driving the > >> convertion of the inode timestamps to timespec64 now, and we will > >> need a new version of utimensat for her work as well. I can see good > >> reasons either way (allowing updates of btime or disallowing them). > > > It would help interop with Windows (and presumably Mac) if birth time can be > updated Ok, thanks. That is certainly a good reason in favor. If nothing else comes up, I guess we can prepare a patch for a new utimensat variant to do this and wait for more comments on that. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC][PATCH 0/6] Enhanced file stat system call Date: Mon, 09 May 2016 15:09:04 +0200 Message-ID: <4211584.odaTcq8sN6@wuerfel> References: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: David Howells , linux-fsdevel , linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , samba-technical , LKML , "linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Deepa Dinamani To: Steve French Return-path: In-Reply-To: Sender: linux-nfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-ext4.vger.kernel.org On Thursday 05 May 2016 21:00:18 Steve French wrote: > On Thu, May 5, 2016 at 5:54 PM, Steve French wrote: > > On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann wrote: > >> On Friday 29 April 2016 13:57:36 David Howells wrote: > >>> struct statx *buffer); > >>> > >>> This is an enhanced file stat function that provides a number of useful > >>> features, in summary: > >>> > >>> (1) More information: creation time, data version number, inode > >>> generation > >>> number and flags. A subset of these is available through a number of > >>> filesystems (such as CIFS, NFS, AFS, Ext4 and BTRFS). > >>> > >> > >> I have a question about birthtime/creationtime: As we are gaining a way > >> to read this, should we also provide a way to update it using a new > >> variant > >> of the utimensat syscall in order to have 'cp -a' create an identical > >> copy, > >> or is the idea that this is defined as the time that is particular copy > >> of the inode was created? > >> > >> I've discussed this with Deepa in the past, as she is driving the > >> convertion of the inode timestamps to timespec64 now, and we will > >> need a new version of utimensat for her work as well. I can see good > >> reasons either way (allowing updates of btime or disallowing them). > > > It would help interop with Windows (and presumably Mac) if birth time can be > updated Ok, thanks. That is certainly a good reason in favor. If nothing else comes up, I guess we can prepare a patch for a new utimensat variant to do this and wait for more comments on that. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html