Copied files have the current date created instead of the original date created

Ask Fedora
1

Been using Fedora as my daily driver for work. Plus I also have clients use Fedora.

One thing I have noticed is that when copying a file or folder from 1 folder to another such as from /home to say /home/Downloads is that the created on the copied file becomes the current date and does not use the original Date created from the original file.

On Windows when copying a file or folder, the copied file and folder has the original date created and is essentially an exact like for like.

From what I have read up on this, is partly due to the file system used and the fact that Linux kernel does not have some form of a way of setting birth time i.e. date created.

But from what I don’t quite follow is btrfs should support setting birth filename but the Linux kernel does not.

So my main question is what work has there been done in the Linux kernel to address this limitation, and how would one go about getting the right people and helping to develop and implement such a fix?

2

I am on my cell phone and can’t type that much but out of interest I asked a LLM chatbot - I think it gave a good answer. Here it is:

DISCLAIMER: The following text has been created using Google’s Gemini

[…] a common technical confusion in Linux: the difference between Modification Time (mtime) and Creation/Birth Time (btime).
The Short Answer
In Fedora (and Linux in general), when you copy a file, the system creates a brand-new file (a new “inode”) on the destination disk. By definition, this new file’s “Birth” or “Creation” date is the moment it was just created. Standard Linux tools like cp and rsync can preserve the Modification Date, but there is currently no standard way to “faking” or “copying” a Creation Date to a new file.

  1. Understanding the different timestamps
    Linux tracks four main timestamps for every file. You can see them by running stat filename in your terminal:
  • Access (atime): When the file was last read.
  • Modify (mtime): When the content of the file was last changed. (This is what most people mean by “Date”).
  • Change (ctime): When the metadata (permissions, owner, etc.) was last changed.
  • Birth (btime): When the file was first created on that specific filesystem.
  1. Why “Date Created” changes
    When you copy a file:
  • The OS creates a new entry on the disk.
  • The filesystem assigns a new “Birth” time to that entry (the current time).
  • The cp command then copies the actual data from the old file to the new one.
  • If you use the archive flag (cp -a), the command will manually set the Modify time to match the original, but it cannot set the Birth time because the Linux kernel does not provide a standard way to change it.
  1. How to preserve the dates that can be kept
    If your goal is to ensure the Modified Date (which most photo viewers and documents use to sort) stays the same, you must use specific flags:

  • Terminal (Recommended): Use the archive flag -a.
    cp -a /source/path /destination/path

    This preserves modification time, permissions, and ownership.

  • GUI (Files/Nautilus): Standard copy-paste usually preserves the modification time, but some file managers or external drives (like FAT32/ExFAT) may handle this inconsistently.

  • Rsync: If you are moving large amounts of data:
    rsync -tav /source/ /destination/

    The -t flag specifically ensures times are preserved.

  1. Can you ever preserve the “Birth” date?
    Technically, no—not through a simple copy. The only ways to keep a “Birth” date are:
  • Moving the file: If you move a file within the same partition (e.g., from ~/Downloads to ~/Documents), the “inode” remains the same, so the creation date doesn’t change.
  • Filesystem Snapshots: On Fedora (which uses Btrfs by default), using btrfs send and btrfs receive to move subvolumes will preserve the original creation timestamps exactly, as it is a block-level transfer rather than a file-level copy.
  • Archiving: Putting files into a .zip or .tar file will “freeze” their modification dates inside the archive, but when you extract them, the newly created files will still get a new “Birth” date for the current time.
    Summary
    If you see the “Date Created” as “Today” in your file manager, look for the “Date Modified” column instead. In the Linux world, mtime (Modified) is considered the “real” age of the file’s content, while btime (Birth) is just the age of that specific copy on your disk.
3

Common Linux filesystems capture file modification date (as well as the metadata change time). Some newer filesystems also capture ”birth” time. cp -p uses the modification date of the source file. https://www.baeldung.com/linux/file-age-and-modification-time has some examples.

4

FYI,

I am a LONG time user of the cinnamon spin and have configured the file manager to list files/directories by MODIFICATION date and in descending order. One benefit is visual evidence if I inadvertently copy a file to a directory other than the intended one.

When using the CLI, i use the command cp -avp which copies and preserves the metadata of the file/directory structure being copied.

I believe that using the GUI has the same effect as cp -avp.

5

Hello Goldmaster! o)

I registered here to give you a precise answer to your question and because most users I encountered so far, don’t really understand the problem if you try to explain the situation to them.

Many seem to mix up Modification- and Creation-Date timestamps or they never used an operating system, where you can actually work with the “Creation Date” and set it to whatever you need it to be. This is the case, if you want to pull 10 year old files from the backup e.g. and would like these 10 year old files to show as 10 year old and not as created “today”. It’s a rather simple and obvious thing. Being able to set the “Creation-Date” is common standard for 30+ years on other operating systems.

So, no, unfortunately you cannot really change the “Creation-Date” or “Birth-Date” of files or folders on BTRFS timestamps or on any other file system on Linux. The Linux kernel has no interface / function to do this.

The only (bad) option you have is:
Write a custom tool / script, which will adjust the system time for each file you copy, so that “when the copy is created” it matches the original creation time. Yes, this is a hack. I don’t know what your “cron” jobs will do if the system date jumps back and forth or what your updating daemon will do. So, I can’t really recommend this approach, I spent multiple days researching this problem, trying to find a way around it, but there is no other (for BTRFS at least).

There is another hack, using “debugfs”, but which only works for EXT4, I did not try this, I’m not interested in using a file system without compression and no other “bells and whistles”.

It seems you can use “btrfs send / receive” to preserve all the time stamps, but this only allows to restore a full snapshot, not individual files and won’t work if you want to you copy files from any “non-BTRFS” location.

If anybody knows better about the “Creation-Date” problem, please share your knowledge!
Thank you in advance! o)

–
Some background information here and some brain storming on how to resolve the problem.

You can read about a discussion and kernel / btrfs file system developers discussing this topic here in the year 2019. That patch never made it into the kernel and no other solution was provided.

The theoretical solution #1 (from my perspective):
Convince the kernel / btrfs file system developer(s) to change their mind about being able to change the “Creation Date” from the user space (very unlikely to happen).

The theoretical solution #2 (from my perspective):
Convince the kernel / btrfs file system developers to at least automatically write an “extended attribute” (xatt) to every file created on the system. Let’s call it “user.date_created”. This attribute would allow to be changed by you, whenever you want.

But:
This will not solve the problem “instantly”, because no Linux software right now will read and use that “user.date_created” attribute and allow you to list your files by your “real” creation date. This would need broader adoption and hundreds of tools would need to adapt their code to support this “extended attribute”. You also want tools to offer the user a choice about what “Creation Date” he likes to use, the file system owned one or the one you have control over.

So, you probably want “ls” to list your files on the terminal by the newly introduced “user.date_creation” attribute instead of “Birth” - owned by the file system, You also want “rsync”, Dolphin, Thunar, Nemo and all the other basic file managers to offer a column “Creation Date (User)” besides the already existing “Creation Date” provided by BTRFS and other file systems.

Is any of this going to happen within the next 10 or 20 years? I doubt it.

Without the support for this new attribute, the new attribute is useless in day to day work, but you could at least migrate / copy some files into Linux and preserve the creation date in that attribute.

I’m in the same boat as you. I have a 30 year history of “Creation Dates” with Windows and the NTFS file system. The moment I copy this over to a Linux machine, I have data-loss. “Meta-data loss” to be specific and it is obvious, that I am not going to do this without a proper solution or standard to handle “Creation Date” as “we” need it.

6

I would like to disagree!
Try this (tested on Debian13+BTRFS), but maybe your Linux is different, which I doubt. o)

> touch file-original.txt
> nano file-original.txt
> stat file-original.txt 
Access: 2026-05-07 06:42:14
Modify: 2026-05-07 06:42:30
Change: 2026-05-07 06:42:30
 Birth: 2026-05-07 06:42:14
> cp -avp file-original.txt file-copy.txt
> stat file-copy.txt 
Access: 2026-05-07 06:42:14
Modify: 2026-05-07 06:42:30
Change: 2026-05-12 13:10:22 <-- Problem!
 Birth: 2026-05-12 13:10:22 <-- Problem!

This is a huge issue for me and a lot of other people, if you look at all the other threads on the internet about this topic.

7

I think I understand. Since I rely on the modification date and not birth or change dates, I have had no problems.

8

Of course you rely on the “Modification Date”, because you cannot rely on “Creation Date” on Linux.

You miss out though, if you only rely on the “Modification Date”, because it is not the same as the “Creation Date” (obviously). So not being able to rely on the “Creation Date” is a downside when using Linux and any of its file systems.

Being able to sort by “Creation Date” gives you another perspective on your files, a timely order of creation (the date you scanned an image, started a project, took a picture e.g.).

The “Modification Date” allows you to see, at what point in time you did changes to anything you created, it is a different “view”, also very useful, but totally different.

We need to be able to use the “Creation Date” on Linux as well, to be as powerful as other systems. The question is, what to do, who do we need to contact, where to create a poll to make this happen!?

Does anyone know or likes to help to resolve this issue?!
Thanks! o)