From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751749AbcEDNqj (ORCPT ); Wed, 4 May 2016 09:46:39 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:64929 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751268AbcEDNqg (ORCPT ); Wed, 4 May 2016 09:46:36 -0400 From: Arnd Bergmann To: David Howells Cc: linux-fsdevel@vger.kernel.org, linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, deepa.kernel@gmail.com Subject: Re: [RFC][PATCH 0/6] Enhanced file stat system call Date: Wed, 04 May 2016 15:46:27 +0200 Message-ID: <5680195.kS2oylQXhI@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160429125736.23636.47874.stgit@warthog.procyon.org.uk> 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:Io45b9t+Om9xSjXHGaSYL6Yi4O9WybyMClG5WCZSlSbjOMTXazq V254/0vXqjIoEWFlL4RmndwztOoXEBNYEi+H8jyEtsYOsg09rR6vqzwVq9xeGQoyOysMYzq BwWINXmAGcSWVVJI9pV75IVmQvCku2QVo6FCp6eqJEBzslV84LwmSktxcNtWN82Sty9E7mo ggy/7yZSpoaJixLjYnd4A== X-UI-Out-Filterresults: notjunk:1;V01:K0:9NmXNkkvSrg=:Fd9bb27TFpwHCfOpvwF8T3 482QwAw7i1ys5lpL/KK5/PqiRRRVcSiImXG3l1oDWbx6aMFtvuiqf0auZ0/vb1oJFNVxfOJWj DI2PAJT613OFelD5sLOaaEMcWuAgwr/DFokwN16VFZfM8B4fGgdJytTB+n27+IwAIjl2WHm1y dThl91sUBSJZO5aNRzAtwtN+U8cvGCaV0pJls/SHlSjViX2UeLWUyRrrpYt6xYY7LUWwBBE/d vKxfjz83kQaG2zOCffH/0KCRD3uEQl+K5XzUV1qt2WQmjpLbMaG/EvUt1txKu+Qs14mfH708r 4WXy3FuYQpGKuuWaC9pGfOINnEHT3tmsQVX9AqOhKPKq5LArUpYA4rN2dow60E2Mf4IZq1rOn 1l/ysIIbx4O9Wf5M/t+LfYOGjKBwC9EimjcTrv1edyx6jx+raXVP2+5JoSog3lkWsn5rHyqPB PwoyPCiRr23DB7XTuIZFPlGaF9JmVKAbA6D8nu8AN3a8BtTMDsso6HMNGrLQ5X01kekurvpSl D/bp6qo1oCAb1Tgiw2oa17EhjAQD1CA/taSXlJ16GWxGbwv/qWdgJzFvMHxW+JwswwJ4FLobw 8CzoGDJZq+bEdkCSGdlNSU8FwOsApSAR/U3B2N20eyRl2uE+CQs/CBR8dSKVqZGtRe2YlYC/R cMYEAxPa5TfoOZAinThNCIt/7dScMoAvldyj3cA8dvsBOkV1ovo020FjNhqrsTOaRxBPw3BKV 99Xg1GmcdB/URKvy Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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). This should not hold up the statx syscall from getting merged as soon as we can, but I'd like to know what everyone feels about that question now that they are looking at the interface already. Arnd