linux-ext4 - Re: [RFC PATCH 0/6] Allow setting file birth time with utimensat()

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]

Date:   Fri, 15 Feb 2019 18:25:18 +0000
From:   Hans van Kranenburg <Hans.van.Kranenburg@...dix.com>
To:     Omar Sandoval <osandov@...ndov.com>
CC:     "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        "kernel-team@...com" <kernel-team@...com>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-btrfs@...r.kernel.org" <linux-btrfs@...r.kernel.org>,
        "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
        "linux-f2fs-devel@...ts.sourceforge.net" 
        <linux-f2fs-devel@...ts.sourceforge.net>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>
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 <osandov@...com>
>>>
>>> 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.

Thanks,
-- 
Hans van Kranenburg