Modification vs Change time

Sometimes you have deployed something to one server, find that one value in a configuration file is wrong and you want to change it. You have permissions, you are not changing any code, it's the same that was deployed to a lower environment and everyone was happy with... it's just a typo in a server name/port whatever... in a config file. But ideally everything should have been correct since the beginning, when your complex deployment scripts deployed it all. If you modify that file by hand if later on someone is navigating that folder he'll notice with a simple "ls -la" that one of the config files there has a different modification date, and maybe will say "hey, so in the end there was an error and you had to do some extra changes... bla, bla, bla". Not a big deal, but maybe you want to avoid that kind of remarks...

Files in Linux have 3 timestamps (Last Modification time, Last Access time and Last Changed time). There is a fourth one, Birth, for the creation time. This value is available in File Systems like Ext4, but most Linux tools do not read it (as the creation time is not defined in the POSIX standard). You can see all these values with the stat.

When you list the files in one folder (e.g. ls -la) the date that you see is the Modification time. The OS will always update the Change time of one file when you modify anything in it (contents, permissions, name, location), but for the Modification time things are more relaxed. If you rename a file or move it to another location, the modification time remains the same. If you do a copy of a file, by default the new file gets its Modification time set to the current datetime, but we are allowed to prevent this by means of the -p (preserve) flag. cp -p myFile myFileCopy will set the Modification time (and Access time) to the value of the source file (but for sure the Change value is set to the current time).

Even more interesting than the above is the fact that you can set the Access and Modification time of one file to an arbitrary value. For that we use the touch -r command. With that I can create a new file with the timestamps of a "source" file. Then I can freely modify the contents of my "source" file and then copy the original timestaps from the new file to the source file. Example:

//create the new file with the timestamp for later reuse touch -r db.conf db.conf.timestamp //modify db.conf correcting some values vi db.conf //db.conf Modify timestamp has changed, let's set it back to the initial value touch -r db.conf.timestamp db.conf rm db.conf.timestamp

With the above, at first sight (with ls) it looks as if both config files had not changed. Obviously checking more in depth (with "stat") will show you the true in the Change timestamp. We could say that this is a sort of "cosmetic trick".