8

Note: Question although says vice versa but it really does not have any meaning since both of them point to the same inode and its not possible to say which is head and which is tail.

Say I have a file hlh.txt

[root@FREL ~]# fallocate -l 100 hlh.txt

Now if I see the change time for hlh.txt

[root@FREL ~]# stat hlh.txt
  File: hlh.txt
  Size: 100             Blocks: 8          IO Block: 4096   regular file
Device: fc00h/64512d    Inode: 994         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-01-11 01:43:05.469703330 -0500
Modify: 2023-01-11 01:43:05.469703330 -0500
Change: 2023-01-11 01:43:05.469703330 -0500
 Birth: 2023-01-11 01:43:05.469703330 -0500

Creating hard link

[root@FREL ~]# ln hlh.txt hlt.txt

Since both hlh.txt and hlt.txt points to same inode, so change time would be the ctime of the hard link tail file which is understood.

[root@FREL ~]# stat hlt.txt
  File: hlt.txt
  Size: 100             Blocks: 8          IO Block: 4096   regular file
Device: fc00h/64512d    Inode: 994         Links: 2
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-01-11 01:43:05.469703330 -0500
Modify: 2023-01-11 01:43:05.469703330 -0500
Change: 2023-01-11 01:44:05.316842644 -0500
 Birth: 2023-01-11 01:43:05.469703330 -0500

But if I unlink the head file, that changes ctime of the file as well. Why? I mean all we did is delete the head, what significance does change time have here internally. Why does it need to be change?

[root@FREL ~]# unlink hlh.txt
[root@FREL ~]#
[root@FREL ~]# stat hlt.txt
  File: hlt.txt
  Size: 100             Blocks: 8          IO Block: 4096   regular file
Device: fc00h/64512d    Inode: 994         Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:admin_home_t:s0
Access: 2023-01-11 01:43:05.469703330 -0500
Modify: 2023-01-11 01:43:05.469703330 -0500
Change: 2023-01-11 01:47:49.588364704 -0500
 Birth: 2023-01-11 01:43:05.469703330 -0500
1
  • 4
    I guess "number of links" is part of the status of a file and thus changes in that number are deemed to warrant a change in ctime
    – Bakuriu
    Jan 11, 2023 at 16:49

1 Answer 1

13

This is a requirement on the unlink() library function by POSIX:

Upon successful completion, unlink() shall mark for update the last data modification and last file status change timestamps of the parent directory. Also, if the file's link count is not 0, the last file status change timestamp of the file shall be marked for update.

The standard document does not expand on this requirement. Since the link count is decreased by one, I'm assuming the ctime timestamp (the "last file status change timestamp") is updated to reflect the fact that the file's status changed.

1
  • 4
    Your assumption is almost certainly correct. The link count is part of the data returned by stat(), and as a general rule, if any of that data other than the timestamps changes, the ctime is supposed to change as well. Jan 11, 2023 at 20:28

You must log in to answer this question.

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