Why does this use of `cp -a` not preserve creation time?

Question

I copy some directories with -a in order to preserve=all which I understood would include creation times:

cp -a ./* /mnt/destination/

When inspecting the resulting directories in the destination they all have creation time set to the current time, while their contents seem to have preserved their creation times.

Why aren't the creation dates of the top level directories preserved?

The source is HFS+ and the destination is btrfs.

---

Excerpts of directory listings of destination and source:

$ ls -hal --time=creation
total 16K
drwxrwxr-x 1 andreas andreas   74 sep  2 23:25  .
drwx------ 1 andreas andreas  310 apr 26 17:08  ..
drwx------ 1 andreas andreas 2,3K sep  2 23:45  Library

$ ls -hal --time=creation /mnt/source
total 8,1M
drwxrwxr-x  1 andreas andreas   15 mar 28  2022  .
drwxr-x---+ 3 root    root    4,0K aug  9  2022  ..
drwx------  1 andreas andreas   95 apr 15  2019  Library

Update

Judging by the answers and comments I concluded that I must have made a mistake when I inspected the dates of subdirectories. I did. My fault — my expectations of the result blinded me of what I was looking at. That part of the question has been dropped.

Answer 1

Traditional unix filesystems don't have creation time, only ctime. ctime is change time, not creation time. Change time can't be set via OS calls except to change it to the current time. Changing permissions or changing atime or mtime will set ctime to the current time.

Having said that, it seems that even though creation time is not part of POSIX, many filesystems seem to have added it, see What file systems on Linux store the creation time?

However, even for filesystems that support it, it isn't standardized, so support for creation time in POSIX tools is not guaranteed, and even on filesystems that support it, it may not be set. If you are seeing it set some times and not others, or not consistently set, possibly multiple tools with varying support are involved, or there is only partial support in those tools.

The linux specific statx function call supports atime, btime, ctime, and mtime, where btime is marked as creation time. However, this only reads the times. (Note that various filesystems reference creation time in various ways including birthtime btime crtime and otime.)

Digging deeper, gnu coreutils cp documents setting time via the utimensat function call, which claims POSIX-1.2008 conformance. This call only supports modifying atime and mtime but researching this, I could not determine if this is because POSIX only supports atime and mtime (with ctime not settable), or if it is because both ctime and btime are basically immutable, changes only allowed by the operating system, setting them to the current time at the appropriate events.

Answer 2

The only time stamps that can be set to arbitrary values (using the utime(), utimes(), utimensat(), futimens() system calls) are the last modification time aka mtime and last access time aka atime.

The change status time aka ctime and birth/creation time (btime/crtime) where supported can't be faked (set arbitrarily), so cp -a, like any other software cannot create a file with a birth time other than that corresponding to the time it was created.

Doing a ln foo bar inplace of cp foo bar or using the -l option of GNU cp would result in bar having the same timestamps including creation time as foo, but note that in that case, foo and bar are the same file (with two different names).