File birth time changing when file modified using btrfs

I’ve finally started my migration from the over-controlling world of Windows to move forward with Linux. :grinning:
I chose OpenSUSE after seeing many good reports and particularly because I wanted the benefits & features of the btrfs file system. (In particular, low cost snapshots).
I want to move many hundreds of my windows files (NTFS) to my new OpenSUSE installation, but preserve the creation time and modification time of all the files.
Creation time seems to be a contentious issue in Linux as it wasn’t apparently included in the original Posix standard.
However, I was pleased to see that many Linux distros, including OpenSUSE (btrfs) do include a “Birth” time.

I performed the following test:

  1. Create an empty file:

me-Suse@localhost:~/Documents> touch test-file-times

  1. Check file meta-data with stat:
me-Suse@localhost:~/Documents> stat !$
stat test-file-times
  File: test-file-times
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 0,49	Inode: 20535       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ me-Suse)   Gid: ( 1000/ me-Suse)
Access: 2024-10-26 18:47:32.849552137 +1300
Modify: 2024-10-26 18:47:32.849552137 +1300
Change: 2024-10-26 18:47:32.849552137 +1300
 Birth: 2024-10-26 18:47:32.849552137 +1300
  1. Modify the file:

me-Suse@localhost:~/Documents> vi test-file-times

  1. Re-inspect file meta-data with stat:
me-Suse@localhost:~/Documents> stat test-file-times
  File: test-file-times
  Size: 5         	Blocks: 8          IO Block: 4096   regular file
Device: 0,49	Inode: 20548       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/ me-Suse)   Gid: ( 1000/ me-Suse)
Access: 2024-10-26 18:48:15.301208989 +1300
Modify: 2024-10-26 18:48:15.301208989 +1300
Change: 2024-10-26 18:48:15.447881938 +1300
 Birth: 2024-10-26 18:48:15.301208989 +1300

I could accept that Access & Change times were also updated with the Modify time but surely the Birth time should NOT have been touched!

This looks like a bug to me but given my lack of Linux, OpenSUSE & btrfs experience, I wonder if I’ve inadvertently caused the issue.

Any and all enlightenment welcome!

Welcome to the forum.

This is not OpenSUSE or btrfs specific, this is the OS, i.e. Linux. If you want to see some details, see “man 2 statx

I did do some experiment and Birth is not what I would think it is, if I edit a file, both the Birth and Change is updated to very recent times. I guess the OS not actually changed the file but created a new file object for it.

Starting your post with derogatory statement about other operating system and then shouting for no real reason is not the best way to introduce yourself to a new community.

vim created new file. Read the vim documentation, specifically the description of the writebackup option. You may need to follow other links in this description to get the full picture.

Thanks @marel,
I think you’ve put me on the right track!
After further digging, it does seem that “Birth” time is set deep in the internals of Linux when any file object is created, and it isn’t always obvious when a program creates a new file, (as in my example above). This behaviour seems consistent across Linux FileSystems (I tried ext4) and distros (I tried Fedora btrfs).
So if I’m now understanding this correctly, then my goal of transferring my NTFS files over to Linux and preserving their creating date may not be possible, at least using the “Birth” time. Or are there yet other mechanisms in Linux that may help achieve my goal?

You mean it is possible from NTFS to NTFS? If you can fake creation time, then creation time loses its meaning.

It seems that you should do some reading about Unix/Linux time stamps of files. Timestamps are not “deep in the internals of Linux” (well, that may be your personal observation), they are in the inodes that are integral parts of a file systems layout/administration and contain meta data about each file in the file system. POSIX standard requires three time stamps:

  • mtime: last time the file is changed;
  • atime: last time the file is accessed;
  • ctime: last time the inode of the file is changed.

A file system type may support additional time stamps (and yes, some types have btime).

You could try to find more detailed information using seach terms like: atime ctime, …

This is of course all about Unix/Linux file systems. If there are similarities between non-Linux file system and how they are translated or faked when such a non-Linux file system is mounted on a Linux system is up to the software that supports these non-Linux file systems. But indeed, they may be faked like the owner:group and permissions (also stored in the inodes) are.

Hi OP!

Welcome to the show! This forum has some competence, but social competences of some posters are limited at best.

Enjoy linux anyway and opensuse is not the only girl at the party, find your favourit over the years… :wink:

If you want to preserve existing timestamps, consider extended attributes, known as xattr. For example

$ touch test_xattr
$ setfattr --name=user.creationtime --value=20241029T1015 test_xattr 
$ getfattr --encoding=text --dump test_xattr 
# file: test_xattr
user.creationtime="20241029T1015"

$ vi test_xattr 
$ cat test_xattr 
do your worst, vi
$ echo 'victory, sweet victory' >> test_xattr 
$ cat test_xattr
do your worst, vi
victory, sweet victory
$ getfattr --encoding=text --dump test_xattr
# file: test_xattr
user.creationtime="20241029T1015"

The naming of the getfattr command is perhaps a bit cheeky.

1 Like

Doesn’t that mean that the TO would need to set the attributes on several hundreds/thousands/million files manually as he wants to copy them from NTFS to btrfs…?

Why manually? Are you pulling my leg @hui? Surely that would be done with a script or two? I just wanted to demonstrate that operations that change btime (actually otime on BTRFS) won’t change the xattr.

The idea is that there are two conceptions for timestamps, the stable original creation time, which is what I think he is concerned with, and the filesystem specific creation time associated with an inode. You can have both if that’s desired.

I also checked if a btrfs send | receive preserves the xattr, and indeed it does. Happy days.

But the origin is NTFS and not BTRFS. Hence the question…

No question that the preservation of the xattr works when used on the same filesystem as you showed. But between different filesystems…?

Worst case scenario would be having to do the read part on Windows (first script writing out filepaths->timestamps), then apply on Linux (second script). Best case is when Linux can read the correct attribute directly from NTFS, whatever corresponds to the actual creation time, ideally using standard tools.

Let’s see, Using Extended Attributes · tuxera/ntfs-3g Wiki · GitHub shows how ntfs-3g maps the ntfs timestamps to an xattr. That’s promising as you should be able to use a copying tool that preserves the xattr. However I don’t know if that’s actually ready for general use or not. Another idea to look into would be Windows file sharing / samba.

Once it’s safely inside an xattr, it would be compatible with most Linux filesystems. Although one might need a few custom scripts if this should be a regular part of the user’s workflow.

Oddly enough I’m not sure what a “standard” xattr name would be for this, I just went with user.creationtime because that made sense.

This might shed some light - they mention that only newer filesystems support original creation time, etc:

Yes, it is. Windows allows setting creation time from user space. Whether creation time will actually be preserved, depends like in Linux on the specific application. Windows Explorer preserves creation time when moving files between different filesystems. OTOH I have a bunch of files with modification time before creation time (like modified in year 2019 and created in year 2023).

Linux kernel does not offer any API to either move files between file systems preserving their attributes (in this case user space program creates the new file and deletes the old one) or to set file creation time from user space. So, the answer to the original question

is - no, it is not possible in Linux. It is unrelated to the source being NTFS, it is the same between two Linux filesystems.

1 Like

Guys, if you take a look at the link to the ntfs-3g documentation that I posted above you’ll find that since 2010 it’s been mapping all of the NTFS timestamps, including creation time, to a couple of extended attributes. As always, the only sensible answer is of course Linux can do it. btime, however, is a red herring.

I found some time (bad pun?) and dug out an NTFS formatted disk (hopefully my beloved butter eff ess won’t mind) and checked if this actually works and I can confirm that it works just fine, using Tumbleweed’s defaults. The only inconvenience is that they have to be converted to a different xattr namespace, and, optionally, to a less idiosyncratic format. They can’t be copied directly with cp --preserve=xattr because they are in the system namespace. Specify the exact name with getfattr -n and then setfattr as desired.

Looks like there’s a mount option to automatically map them to the user prefix with a little extra configuration, then you could copy them directly, but it’s hidden behind a compile-time option that probably isn’t selected in Tumbleweed. Doesn’t much matter because we can read the time stamps and write them to whatever xattr we want, in whatever format we like.

Because we can do anything we want. It’s just a matter of learning how. (Even change the btime but I’ve been advised to tell you that you shouldn’t do that, that sort of thing makes fs devs grimace.)

Decoded xattr originally from NTFS, now user xattr on BTRFS:

Creation : 2024-10-30 23:48:10.199812100+00:00
Modify   : 2024-10-30 23:48:35.221110700+00:00
Access   : 2024-10-30 23:49:01.423688100+00:00
internal : 2024-10-30 23:49:01.423688100+00:00
1 Like

Thanks for both these promising hints; xattr & samba.
I thought I’d give samba a try because I have a Synology DSM NAS which I believe is Linux & btrfs “under the hood” and transferring my files from Windows to the NAS (using Fastcopy which preserves creation time) appears to work as I wanted.
So I installed samba server on my OpenSuse machine (I’m loving Yast!) to try it out. Strangely viewing my files on OpenSuse from Windows with File Explorer shows exactly the same attributes as the original files on Windows, but viewing them on OpenSuse with stat or Nautilus, shows a “Creation/Birth time” = copy time!
I notice there are lots of possible configuration options for the smb.conf file which may give my desired effect, but I’m thinking now to investigate your other suggestion using xattr, which I was totally unaware of and I can imagine offers lots of potential for manipulating file metadata.
I think my next most beneficial learning task after this will be Linux scripting !
(So much to learn in Linux land!)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.