Why does renaming a file with mv command alter an inode's "change" date & time?

Question

A file hello.c is renamed to hi.c. As the output of stat command shows, [change] time stamp has been changed. usually it is changed when inode of file got modified. Why renaming with mv command changes the content of inode and actually which attribute is modified?

xyz@linuxPC:~/Documents$ stat hello.c
 File: ‘hello.c’
 Size: 568          Blocks: 8          IO Block: 4096   regular file
Device: 809h/2057d  Inode: 261889      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ xyz)   Gid: ( 1000/ xyz)
Access: 2015-04-22 19:54:34.889330399 +0530
Modify: 2015-04-22 19:54:34.241330427 +0530
Change: 2015-06-21 15:46:45.365465523 +0530
Birth: -
xyz@linuxPC:~/Documents$ mv hello.c hi.c
xyz@linuxPC:~/Documents$ stat hi.c 
 File: ‘hi.c’
 Size: 568          Blocks: 8          IO Block: 4096   regular file
Device: 809h/2057d  Inode: 261889      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ xyz)   Gid: ( 1000/ xyz)
Access: 2015-04-22 19:54:34.889330399 +0530
Modify: 2015-04-22 19:54:34.241330427 +0530
Change: 2015-06-21 15:48:23.361469822 +0530
Birth: -

Answer 1

I got intrigued myself and did a little digging. At first I thought that's some kind of a side effect, e.g. the node gets 2 links and then the original link is deleted and ctime is more of an accident than a deliberate action.

In case it is unclear for someone, the file is represented by an inode which has nothing to do with the name. The inode "knows" how many names it got thanks to the hardlink counter, but it has zero clue as to what those names are or in what directories these reside.

With this in place let's take a look at POSIX ( http://pubs.opengroup.org/onlinepubs/009695399/functions/rename.html ):

Some implementations mark for update the st_ctime field of renamed files and some do not. Applications which make use of the st_ctime field may behave differently with respect to renamed files unless they are designed to allow for either behavior.

And example implementation (http://lxr.free-electrons.com/source/fs/xfs/xfs_inode.c#L2985):

/*
 * We always want to hit the ctime on the source inode.
 *
 * This isn't strictly required by the standards since the source
 * inode isn't really being changed, but old unix file systems did
 * it and some incremental backup programs won't work without it.
 */
xfs_trans_ichgtime(tp, src_ip, XFS_ICHGTIME_CHG);

So there.

Answer 2

A long, long time ago, the command

mv oldpath newpath

was implemented inside mv.c as

link(oldpath, newpath);
unlink(newpath);

Now we have a system call

rename(oldpath, newpath);

but apparently it still works the same way, inside the kernel.  This is a conjecture on my part, but it’s based on the fact that one of the failure modes for rename(2) is

EMLINK

oldpath already has the maximum number of links to it, or ...

and based on the experimental data that you reported (and that I confirmed on my own system).

And so...

When oldpath gets linked to newpath, the inode’s link count goes up by one.  When oldpath gets unlinked, the inode’s link count goes down by one. Therefore, the inode gets changed (even though it immediately gets changed back to the way it was before).

---

P.S. It’s interesting to note that the POSIX document lists EMLINK as a possible error return code, but not for the case of file-to-file rename.

Answer 3

Nothing in the file's inode changes so ideally ctime should not change on rename, but it's a convenient way to highlight this file to backup programs telling that that something about the file changed. Thus for backup programs, checking for "ctime newer than last backup time" is the sufficient check to find out all files which have changed in any way, since the last backup.