public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Artem S. Tashkinov" <aros@gmx.com>
Cc: linux-ext4@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: A syscall for changing birth time
Date: Mon, 10 Mar 2025 11:37:44 -0400	[thread overview]
Message-ID: <20250310153744.GD8837@mit.edu> (raw)
In-Reply-To: <69d8b100-f65d-470f-a957-2819795e82a4@gmx.com>

On Mon, Mar 10, 2025 at 02:11:13PM +0000, Artem S. Tashkinov wrote:
> 
> I'm not going to argue with your reasoning but being able to set btime
> could be beneficial for backup and restore purposes/utilities.

I think the fundmental question is should we change the current
defined semantics of btime, versus adding some new "crtime" field for
those people who care about Windows compatibility.

Granted, it's only been relatively recently that userspace could even
*access* btime for a file in the a mounted file system via the
statx(2) system call.  So there might not be that many users of btime
today, so changing the semantics might not break userspace (much).

Again, the choices are:

* Change semantics of "birth time" for everyone as of some new kernel version

* Make the semantics of "birth time" be subject to chagge via a mount option

* Add the ability to optionally store a new "creation time" which as
  Windows semantics in addition to btime.  This could either be via an
  xattr, or by adding a new on-disk inode field for some file systems
  that care about Windows compatibility.

> Secondly, I really like having separate modification and creation times
> for all my files.

Personally, I don't find it all that useful, since "creation time" is
really (with apologies to Lewis Carroll):

   “When I use a timestamp,’ Humpty Dumpty said in rather a scornful tone, ‘it
    means just what I choose it to mean — neither more nor less.’

    ’The question is,’ said Alice, ‘whether you can make timestamps mean so
    many different things.’

    ’The question is,’ said Humpty Dumpty, ‘which is to be master — that’s all.”

.... combined with the fact that most file systems don't support
creation time today.

Hence I find it more useful to find some other way to do version
stamping --- and something more reliable, like a SHA1 hash like git
uses.  Or as a nother example, using an external database, such as a
rpm or dpkg installed package database, with a crypto hash to verify
whether the file has actually changed, no matter what the package
manager thinks.

But that's just my personal opinion.  I am sure that other people
might find "creation time" to be useful.

> Finally, as for POSIX not offering this feature - doesn't Linux already
> have a lot of syscalls that are not found in POSIX?

What I was trying to point out that there is precedent in POSIX not
allowing certain timestamps to be changed, because that would violate
the semantics of ctime --- and the same would apply for btime's
current semantics.

Can we forcibly change btime's semantics?  Perhaps.  But let's do so
consciously, and not blindly follow Windows' way of doing things.

Cheers,

	     	     	     	    	     	 - Ted

  reply	other threads:[~2025-03-10 15:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10  7:26 A syscall for changing birth time Artem S. Tashkinov
2025-03-10 13:58 ` Theodore Ts'o
2025-03-10 14:11   ` Artem S. Tashkinov
2025-03-10 15:37     ` Theodore Ts'o [this message]
2025-03-11 16:08       ` David Sterba
2025-03-11 21:14         ` Theodore Ts'o
2025-03-10 22:12   ` David Laight
2025-03-11  0:31     ` Al Viro
2025-03-11  4:49     ` Theodore Ts'o
2025-03-11  4:56       ` Al Viro
2025-03-11 17:07         ` Theodore Ts'o
2025-03-11 18:11           ` Al Viro
2025-03-11 20:01           ` David Laight

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=20250310153744.GD8837@mit.edu \
    --to=tytso@mit.edu \
    --cc=aros@gmx.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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