0

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
Andreas
  • 399
  • 3
  • 12
  • 1
    Please edit your question and show us how you are checking creation times. Ideally, show us what you are copying, where from, and where to, so we can try and reproduce locally. Are you sure you're not looking at modification time which will be changed since you just moved something into those directories? – terdon Sep 02 '23 at 22:47
  • @terdon Thanks. I added `ls` outputs. The first indicator was in the "Created" column in Ubuntu's Files app though. Not sure of the exact details needed to recreate it, but it's from files copied by macOS to a HFS+ formatted USB stick to btrfs on a USB attached HDD, using Ubuntu 23.04 on a Raspberry Pi 4. The example shows my macOS user's Library directory copied "exactly" by macOS Ventura's Finder onto the source volume. – Andreas Sep 02 '23 at 23:22
  • To preserve times, perhaps use rsync instead: rsync -a ./ /mnt/destination/ – D McKeon Sep 02 '23 at 23:33
  • @DMcKeon Thanks for the tip. I mostly want to clear up potential gaps in my understanding, since I think it would be convenient to have confidence in `cp` as well. – Andreas Sep 02 '23 at 23:38

1 Answers1

0

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.

user10489
  • 5,834
  • 1
  • 10
  • 22
  • Thanks. If we assume creation times do not actually exist on btrfs, or even if there's just no api to set it, then it's still inexplicable how the *contents* of the directories had their same time stamp fields (`time=creation` in `ls`) set to the actual original dates (i.e. years ago) during the copy. If I understood you right, these times should also have been set to the current time. I would have expected `cp` to be consistent with the same field. – Andreas Sep 02 '23 at 23:29
  • btrfs might be one of the ones that has a creation time. It is possible that `cp` doesn't know how to set it. – user10489 Sep 03 '23 at 01:31
  • Did I understand you correctly that you're suggesting that `cp` only has to know how to set that field for the top level directories being transferred? Then how do subdirectories have their fields set? – Andreas Sep 03 '23 at 02:19
  • It could also be a bug in cp. But considering that POSIX doesn't support creation time, it's surprising if cp does anything with it. – user10489 Sep 03 '23 at 04:12