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@xxxxxx> >>> >>> 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
