linux-kernel - Re: A syscall for changing birth time

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250311160839.GG32661@twin.jikos.cz>
Date: Tue, 11 Mar 2025 17:08:39 +0100
From: David Sterba <dsterba@...e.cz>
To: Theodore Ts'o <tytso@....edu>
Cc: "Artem S. Tashkinov" <aros@....com>, linux-ext4@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: A syscall for changing birth time

On Mon, Mar 10, 2025 at 11:37:44AM -0400, Theodore Ts'o wrote:
> 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.

>From my experience and use case: for archiving purposes the creation
time has a meaning and it gets lost when the files get moved to bigger
storage. Sometimes the creation is stored in the file metadata (like jpeg
or video files), but ultimately the creation time is stored in the file
inode metadata itself regardless of the format.

Another use case is for send/receive that transfers snapshots from one
btrfs filesystem to another. In protocol v2 we added the creation time
(otime) to the stream so the receiving side can read it, but cannot
write it yet.

Question about ability to change otime/btime can be found around
internet, there was attempt to make it a utimensat() operation
(https://lore.kernel.org/linux-btrfs/cover.1550136164.git.osandov@fb.com).

In that thread there's a disagreement with providing that and I
disagreed as well back then, but over the time I changed my mind also
because I found a use case for myself.  So I have a WIP to add it as
ioctl to btrfs. I understand it's a niche use case and won't attempt to
implement it on the VFS level. At least for btrfs and the send/receive
use case it's slightly more justified than in other filesystems.