From: Andy Lutomirski <luto@kernel.org>
To: Adam Borowski <kilobyte@angband.pl>
Cc: Boaz Harrosh <openosd@gmail.com>,
Dave Chinner <david@fromorbit.com>,
Omar Sandoval <osandov@osandov.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
kernel-team <kernel-team@fb.com>,
Linux API <linux-api@vger.kernel.org>,
Linux btrfs Developers List <linux-btrfs@vger.kernel.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-f2fs-devel@lists.sourceforge.net,
linux-xfs@vger.kernel.org
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()
Date: Sun, 17 Feb 2019 12:40:09 -0800 [thread overview]
Message-ID: <CALCETrWsCUTSbvwemKHB=8=pO4fwK2qD0boFEd4puBDkpb3F9g@mail.gmail.com> (raw)
In-Reply-To: <20190217175450.psaesabv3vlzvjv4@angband.pl>
On Sun, Feb 17, 2019 at 9:55 AM Adam Borowski <kilobyte@angband.pl> wrote:
>
> On Sun, Feb 17, 2019 at 06:35:25PM +0200, Boaz Harrosh wrote:
> > On 15/02/19 00:06, Dave Chinner wrote:
> > > So you're adding an interface that allows users to change the create
> > > time of files without needing any privileges?
>
> > > Inode create time is forensic metadata in XFS - information we use
> > > for sequence of event and inode lifetime analysis during examination
> > > of broken filesystem images and systems that have been broken into.
>
> > I think the difference in opinion here is that there are two totally
> > different BTIme out in the world. For two somewhat opposite motivations
> > and it seems they both try to be crammed into the same on disk space.
> >
> > One - Author creation time
> > Two - Local creation time
>
> > So it looks like both sides are correct trying to preserve their own guy?
>
> I'd say that [2] is too easily gameable to be worth the effort. You can
> just change it on the disk. That right now it'd take some skill to find the
> right place to edit doesn't matter -- a tool to update the btime against
> your wishes would need to be written just once. Unlike btrfs, XFS doesn't
> even have a chain of checksums all the way to the root.
>
> On the other hand, [1] has a lot of uses. It can also be preserved in
> backups and version control (svnt and git-restore-mtime could be easily
> extended).
>
> I'd thus go with [2] -- any uses for [1] are better delegated to filesystem
> specific tools.
>
I started out in the Windows world, and I found it quite handy to
right-click a file and see when it was created. When I started using
Linux, I saw things like this:
Access: 2019-02-16 22:19:32.024284060 -0800
Modify: 2016-02-02 19:26:47.901766778 -0800
Change: 2016-02-02 19:26:47.907766649 -0800
and my mind boggled a bit. Modify makes sense. Change? What's that?
Why do I care?
Adding "birth" makes sense, and I think that filesystem-agnostic
backup tools *should* be able to write it.
So I'm highly in favor of this patch. If XFS wants to disallow
writing the birth time, fine, but I think that behavior should be
overridable.
next prev parent reply other threads:[~2019-02-17 20:40 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 [this message]
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
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='CALCETrWsCUTSbvwemKHB=8=pO4fwK2qD0boFEd4puBDkpb3F9g@mail.gmail.com' \
--to=luto@kernel.org \
--cc=david@fromorbit.com \
--cc=kernel-team@fb.com \
--cc=kilobyte@angband.pl \
--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=openosd@gmail.com \
--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).