From: Hans van Kranenburg <Hans.van.Kranenburg@mendix.com>
To: Omar Sandoval <osandov@osandov.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"kernel-team@fb.com" <kernel-team@fb.com>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>,
"linux-f2fs-devel@lists.sourceforge.net"
<linux-f2fs-devel@lists.sourceforge.net>,
"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()
Date: Fri, 15 Feb 2019 18:25:18 +0000 [thread overview]
Message-ID: <d0f971c8-5b86-0f4f-7009-fdb199b7e820@mendix.com> (raw)
In-Reply-To: <20190215053950.GF9819@vader>
On 2/15/19 6:39 AM, Omar Sandoval wrote:
> On Fri, Feb 15, 2019 at 01:57:39AM +0000, Hans van Kranenburg wrote:
>> Hi,
>>
>> On 2/14/19 11:00 AM, Omar Sandoval wrote:
>>> From: Omar Sandoval <osandov@fb.com>
>>>
>>> Since statx was added in 4.11, userspace has had an interface for
>>> reading btime (file creation time), but no way to set it. This RFC patch
>>> series adds support for changing btime with utimensat(). Patch 1 adds
>>> the VFS infrastructure, patch 2 adds the support to utimensat() with a
>>> new flag, and the rest of the patches add filesystem support; I excluded
>>> CIFS for now because I don't have a CIFS setup to test it on.
>>>
>>> Updating btime is useful for at least a couple of use cases:
>>>
>>> - Backup/restore programs (my motivation for this feature is btrfs send)
>>
>> Can you give an example of such usefulness? What's the thing you run
>> into that you can't do without having this?
>
> That boils down to what's useful about having the file creation time,
> and it's really just another tidbit of information which you may or may
> not care about. Maybe you have a document that you've been editing for
> awhile, and you want to know when you started working on it. Or, you
> want to know when a user created some directory that they keep adding
> files to.
>
> If the file creation time is useful to you, then you likely want it
> preserved if you have to restore from backups. If I had to restore from
> backups yesterday and I'm trying to figure out when I started that
> document, I don't care that I restored that file yesterday, I want the
> real creation date.
>
> If you've never wondered when a file was created, then I'm sure you
> won't care whether btrfs send/receive preserves it :)
Thanks for the elaborate answer. I was just curious if this was to make
send "more feature complete" or if there was something else special to
it, and it seems to be the first one. ;]
And for myself, I mostly treat btrfs send/receive like a improved
replacement for rsync and usually don't care that much about btime indeed.
Thanks,
--
Hans van Kranenburg
next prev parent reply other threads:[~2019-02-15 18:25 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-14 10:00 [RFC PATCH 0/6] Allow setting file birth time with utimensat() Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 1/6] fs: add btime to struct iattr Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 2/6] fs: add AT_UTIME_BTIME for utimensat() Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 3/6] Btrfs: add support for setting btime Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 4/6] ext4: " Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 5/6] f2fs: " Omar Sandoval
2019-02-14 10:00 ` [RFC PATCH 6/6] xfs: " Omar Sandoval
2019-02-14 10:00 ` [PATCH] generic: add a test for AT_UTIME_BTIME Omar Sandoval
2019-02-14 10:00 ` [PATCH] utimensat2: document AT_UTIME_BTIME Omar Sandoval
2019-02-14 10:00 ` [PATCH] xfs_io: add AT_UTIME_BTIME support Omar Sandoval
2019-02-14 22:06 ` [RFC PATCH 0/6] Allow setting file birth time with utimensat() Dave Chinner
2019-02-14 23:14 ` Omar Sandoval
2019-02-15 0:16 ` Dave Chinner
2019-02-15 6:59 ` Omar Sandoval
2019-02-15 13:57 ` David Disseldorp
2019-02-17 1:57 ` Andreas Dilger
2019-02-18 22:18 ` Dave Chinner
2019-02-22 19:00 ` Omar Sandoval
2019-02-23 18:32 ` Andreas Dilger
2019-02-17 16:35 ` Boaz Harrosh
2019-02-17 17:54 ` Adam Borowski
2019-02-17 20:40 ` Andy Lutomirski
2019-02-19 4:04 ` Matthew Wilcox
2019-02-19 4:28 ` Dave Chinner
2019-02-20 7:47 ` Andreas Dilger
2019-02-15 1:57 ` Hans van Kranenburg
2019-02-15 5:39 ` Omar Sandoval
2019-02-15 18:25 ` Hans van Kranenburg [this message]
2019-02-22 15:02 ` David Sterba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0f971c8-5b86-0f4f-7009-fdb199b7e820@mendix.com \
--to=hans.van.kranenburg@mendix.com \
--cc=kernel-team@fb.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).