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  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]
Date:   Fri, 15 Feb 2019 18:25:18 +0000
From:   Hans van Kranenburg <>
To:     Omar Sandoval <>
CC:     "" <>,
        Al Viro <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>
Subject: Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

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 <>
>>> 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.

Hans van Kranenburg

Powered by blists - more mailing lists