0

Im on Linux Mint 21, I have a EXT4 file system
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

i opened a file my_test:

touch my_test
stat my_test
  File: my_test
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: 831h/2097d  Inode: 54          Links: 1
Access: 2023-12-17 22:26:37.610635694 +0100
Modify: 2023-12-17 22:26:37.610635694 +0100
Change: 2023-12-17 22:26:37.610635694 +0100
 Birth: 2023-12-17 22:26:37.610635694 +0100

then edited it with nano

nano my_test
stat my_test
  File: my_test
  Size: 12          Blocks: 8          IO Block: 4096   regular file
Device: 831h/2097d  Inode: 54          Links: 1
Access: 2023-12-17 22:27:32.207040986 +0100
Modify: 2023-12-17 22:27:48.387162937 +0100
Change: 2023-12-17 22:27:48.387162937 +0100
 Birth: 2023-12-17 22:26:37.610635694 +0100

You see birth date exactly the same, then i opened it with libre writer, edited something and saved it

stat my_test
  File: my_test
  Size: 17          Blocks: 8          IO Block: 4096   regular file
Device: 831h/2097d  Inode: 55          Links: 1
Access: 2023-12-17 22:29:06.259760565 +0100
Modify: 2023-12-17 22:29:06.259760565 +0100
Change: 2023-12-17 22:29:06.267760627 +0100
 Birth: 2023-12-17 22:29:06.251760503 +0100

birth date changed - You see there is a new inode - why?

Shell:

echo "hello" > my_test

keeps the birth date

why are libre office writer or xed changing the birth date
this makes the whole sense of birth date useless

are they using the same wrong dynamic library with file system functions ? or what?

1
  • 3
    That's because most apps that edit files usually create a temporary file which is then (when you "save") used to overwrite the original one... Dec 17, 2023 at 22:05

1 Answer 1

2

To be yet a bit more precise than don_crissti's excellent comment which explains the situation:

Programs with complex file type writers tend to write to a temporary file, then rename the temporary file to the original's name, atomically replacing it with the new save.

That has two advantages

  • If you have a bug that makes the program crash during saving, the original remains intact (hopefully that's not a "feature" you ever needed)
  • at no point in time is there a "half-complete" file under the original file name. That makes a lot of differences for programs that automatically update the file when it changes (this can be, for example, your file manager's preview).

But you're right, it makes the ctime of the file irrelevant. At least in libreoffice, you'll find that in the File Properties dialog, the original creation time is still saved – but it's saved within the file itself, not as a file property.

2
  • @don_crissti It's ctime, not crtime; see man 3type stat Dec 18, 2023 at 13:27
  • I was under the impression OP wanted to know why "birth time" changes when editing files. Birth (creation) time is known as crtime or btime depending on the tool used e.g. debugfs calls it crtime while statx(2) defines it as btime Dec 18, 2023 at 14:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .