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 09:58:28 -0400	[thread overview]
Message-ID: <20250310135828.GB8837@mit.edu> (raw)
In-Reply-To: <bda3fa3f-dd12-40de-841a-e4c216ab533f@gmx.com>

On Mon, Mar 10, 2025 at 07:26:00AM +0000, Artem S. Tashkinov wrote:
> 
> Why is it that the Linux kernel supports reading btime, but there's no
> syscall to change it? At least for ext4 there's the debugfs utility, but
> for other filesystems there's just nothing. And even debugfs is not a
> solution, since it requires root privileges and an unmounted/mounted RO
> filesystem.

POSIX and Single Unix Specification also doesn't provide a way to
allow userspace to set ctime (inode change time).  That's because the
definition of "change time" is defined to include the time to change
anything about the inode metadata --- including the inode timestamps.

Simply, the definition of "birth time" is about the time that the
inode was "birthed", and that's not something that you can change.
The problem is that DOS has a concept of "creation time", which seems
to mean "the time that the abstract concept of the file was created".
So if a file was created somewhere in a build farm in Redmond,
Washington, that's the time that the file should have, according to
Microsoft.  So Windows allows the "creation time" to be set to any
arbitrary file, since installers need to be able to set the "abstract
creation time".

You can debate whether "birth time" (which can't be set) or a
"abstract creation time" (which can set to any arbitrary value), is
"better" but that's why Linux doesn't support a way to set the "birth
time".

Whether you think we should bow to what Microsoft dictates probably
depends on how much you believe Windows is a legacy operating system
or not.  :-)  Personally, it's not something I really care about, and
if someone really wants to add a Windows-compatible "Creation Time",
my suggestion would be to define an extended attribute where this
could be stored.

We *could* allocate space in the on-disk inode to store this
timestamp, but since I would estimate 99.9% of deployed Linux systems
don't care about Windows compatibility, it's not a good use of
resources.  We could also add a mount option which changes the
semantics of birth time, but that adds extra complexity, and again, I
would estimate that 99.9% of Linux systems (where I include all of the
Linux deployments in Cloud VM's) don't care about Windows
compatibility in this way.

Cheers,

						- Ted

  reply	other threads:[~2025-03-10 13:58 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 [this message]
2025-03-10 14:11   ` Artem S. Tashkinov
2025-03-10 15:37     ` Theodore Ts'o
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=20250310135828.GB8837@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