0

On my Ubuntu system, I've created a new file prueba.txt using touch prueba.txt. When I show its file statistics using stat prueba.txt, the output is as follows:

  File: prueba.txt
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 4092        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-10-07 13:04:57.621272608 +0000
Modify: 2022-10-07 13:04:57.621272608 +0000
Change: 2022-10-07 13:04:57.621272608 +0000
 Birth: 2022-10-07 13:04:57.621272608 +0000

Then, when I print the contents of the file using cat prueba.txt and then run stat prueba.txt again, the ouput is as follows:

  File: prueba.txt
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fc01h/64513d    Inode: 4092        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-10-07 13:06:18.852005488 +0000
Modify: 2022-10-07 13:04:57.621272608 +0000
Change: 2022-10-07 13:04:57.621272608 +0000
 Birth: 2022-10-07 13:04:57.621272608 +0000

Note that the Access time has changed, but the Change time has not. However, in the man 7 inode entry that describes (among other things) this file metadata, the following information is provided about the meaning of Change:

Last status change timestamp (ctime)
              stat.st_ctime; statx.stx_ctime

              This is the file's last status change timestamp.  It is changed by writing or by setting inode informa‐
              tion (i.e., owner, group, link count, mode, etc.).

If I understand correctly, the Change time should be updated whenever any file data or metadata is modified, including (I assume) the Access metadata. So how is it that cating the file affects the value of its Access metadata, but does not alter its Change metadata in the process? Am I misunderstanding the meaning of this man entry, or misunderstanding how cat works in some way?

3
  • 5
    (i.e., owner, group, link count, mode, etc.) If accessing a file modified it's last changed timestamp that would be a bug.
    – jesse_b
    Commented Oct 7, 2022 at 13:12
  • @jesse_b Is "last accessed" data not part of the inode information? Commented Oct 7, 2022 at 13:14
  • 5
    It doesn't say changing any inode information and it also says "setting inode information" When the last access time is updated you are not setting it, the system is. Again, if it behaved the way you expect it to it would be a bug and would completely negate the purpose of access vs change.
    – jesse_b
    Commented Oct 7, 2022 at 13:16

1 Answer 1

1

Linux keeps three timestamps for each file:

  • mtime: Time of last modification to file contents (data itself). Can be seen via ls -l
  • ctime: Time of last change to file contents or file metadata (owner, group, permissions, link count, etc.). This does not include timestamps. Can be seen via ls -lc
  • atime: Time of last access to file for reading its contents. Can be seen via ls -lu

Reading a file via cat changes its atime, as expected. Neither file contents nor its metadata are changed during this operation, so its ctime is not modified.

1
  • These POSIX links can be handy to dismiss any doubt: write: "Upon successful completion, where nbyte is greater than 0, write() shall mark for update the last data modification and last file status change timestamps of the file" , vs read: "Upon successful completion, where nbyte is greater than 0, read() shall mark for update the last data access timestamp of the file, and shall return the number of bytes read" : no ctime for read.
    – A.B
    Commented Oct 7, 2022 at 15:00

You must log in to answer this question.

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