Getting the creation time of a file under Linux and a practical tutorial

background

Sometimes we need to get the creation time of a file.

For example:

When I was studying the "xtrabackup schematic", I wanted to confirm through observation that xtrabackup_log was the first file created and the last file saved. We need to know the creation timestamp and modification timestamp of the xtrabackup_logfile file.

Review: Three timestamps for Linux files

The Linux file system stores three timestamps, which can be obtained by viewing file information using the stat command. They are ATime, MTime and CTime.

[root@192-168-199-198 backups]# stat 2.txt 
 File: '2.txt'
 Size: 16 Blocks: 8 IO Blocks: 4096 regular file
Device: 821h/2081d Inode: 15 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-07-23 12:12:14.276981038 +0800
Modify: 2019-07-23 12:12:41.415980158 +0800
Change: 2019-07-23 12:12:41.415980158 +0800
 Birth: -

ATime - the last access time of the file

Whenever a file is read, ATime is updated to correspond to the value of Access obtained by the stat command.

[root@192-168-199-198 backups]# cat 2.txt #<-- Read file 121231233123123
[root@192-168-199-198 backups]# stat 2.txt 
 File: '2.txt'
 Size: 16 Blocks: 8 IO Blocks: 4096 regular file
Device: 821h/2081d Inode: 15 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-07-23 12:22:09.644961733 +0800 #<-- The time has changed Modify: 2019-07-23 12:12:41.415980158 +0800
Change: 2019-07-23 12:12:41.415980158 +0800
 Birth: -

MTime - the time when the contents of the file were last modified

When the file is written, CTime will be updated, corresponding to the Modify value obtained by the stat command.

[root@192-168-199-198 backups]# echo hello_world > 2.txt #<-- Modify file content [root@192-168-199-198 backups]# stat 2.txt 
 File: '2.txt'
 Size: 12 Blocks: 8 IO Blocks: 4096 regular file
Device: 821h/2081d Inode: 15 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-07-23 12:22:09.644961733 +0800
Modify: 2019-07-23 12:26:23.466953503 +0800 #<-- The time has changedChange: 2019-07-23 12:26:23.466953503 +0800
 Birth: -

Do not use vi to modify the file content here, because using vi to modify the file content may cause the Inode to change, that is, the file you observe is not the previous file! This is related to the principle of vi.

CTime - the time when the file attributes were last modified

When the file directory is modified, or the file owner, permissions, etc. are modified, CTime will also be updated, corresponding to the Change value obtained by the stat command.

[root@192-168-199-198 backups]# chmod 777 2.txt #<-- Modify file attributes [root@192-168-199-198 backups]# stat 2.txt 
 File: '2.txt'
 Size: 12 Blocks: 8 IO Blocks: 4096 regular file
Device: 821h/2081d Inode: 15 Links: 1
Access: (0777/-rwxrwxrwx) Uid: (0/root) Gid: (0/root)
Access: 2019-07-23 12:22:09.644961733 +0800
Modify: 2019-07-23 12:26:23.466953503 +0800
Change: 2019-07-23 12:30:35.830945320 +0800 #<-- Time changedBirth: -

Linux cannot get file creation time?

Now we know that Linux has three kinds of time, ATime, MTime and CTime, then we are curious why there is no CRTime (creation time)?

Compared with the Windows system (above), there are three timestamps in the Windows NTFS file system, including the "creation time", but there is no such thing as file "creation time" in the design philosophy of Linux, so early versions of the ext file system do not support file "creation time". But starting from the ext4 version, the file creation time is stored in the inode of the ext4 file system, so the ext4 file system can also obtain the file creation time using a special method.

It also explains that whether the creation time of a file can be obtained depends on whether the file system supports it.

Steps to get file creation time on Linux

The CentOS7 Linux system comes with a tool called debugfs, which can find out the creation time of files on the ext4 file system. man debugfs found that the description of the tool is "ext2/ext3/ext4 file system debugger", so it does not support the xfs file system.

It is not clear whether the commonly used xfs file system supports obtaining the file creation time, and how to obtain it. Readers are required to refer to the official documentation

1. Get the inode number of the file

Method 1:

[root@192-168-199-198 backups]# stat /backups/2.txt
 File: '/backups/2.txt'
 Size: 30 Blocks: 8 IO Blocks: 4096 regular file
Device: 821h/2081d Inode: 14 #<--- This Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2019-07-23 12:49:11.462909146 +0800
Modify: 2019-07-23 12:49:11.462909146 +0800
Change: 2019-07-23 13:08:20.138871900 +0800
 Birth: -

Method 2:

[root@192-168-199-198 backups]# ls -i /backups/2.txt
14 /backups/2.txt

Here, the inode number we get is 14.

2. Find the disk path where the file is located

[root@192-168-199-198 backups]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 46G 23G 24G 49% /
devtmpfs 3.8G 0 3.8G 0% /dev
tmpfs 3.9G 8.0K 3.9G 1% /dev/shm
tmpfs 3.9G 12M 3.8G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
/dev/sdb1 100G 77G 24G 77% /data2
/dev/sdc1 50G 53M 47G 1% /backups #<--- You can see that the files are here /dev/sda1 1014M 142M 873M 14% /boot
tmpfs 781M 0 781M 0% /run/user/0

The disk path is /dev/sdc1

3. Use debugfs to view file creation time

[root@192-168-199-198 backups]# debugfs -R 'stat <14>' /dev/sdc1
debugfs 1.42.9 (28-Dec-2013)
Inode: 14 Type: regular Mode: 0644 Flags: 0x80000
Generation: 737271740 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 30
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
 ctime: 0x5d369644:211c1170 -- Tue Jul 23 13:08:20 2019
 atime: 0x5d3691c7:6e5dbb68 -- Tue Jul 23 12:49:11 2019
 mtime: 0x5d3691c7:6e5dbb68 -- Tue Jul 23 12:49:11 2019
crtime: 0x5d3691c7:6e5dbb68 -- Tue Jul 23 12:49:11 2019
Size of extra inode fields: 28
EXTENTS:
(0):35337

Script to get file creation time

Given that getting the file creation time step operation is a bit cumbersome (although there are only three steps :) )

I provide a script here

vi statx

#!/bin/sh

[ $# -ne 1 ] && echo "Usage: $0 {FILENAME}" && exit 1

INODE=`ls -i $1 |awk '{print $1}'`
FILENAME=$1

#If the parameter contains /, get the directory path of the parameter and enter the directory `echo $FILENAME |grep / 1> /dev/null` && { FPWD=${FILENAME%/*};FPWD=${FPWD:=/};cd ${FPWD};FPWD=`pwd`; } || FPWD=`pwd`

 

array=(`echo ${FPWD} | sed 's@/@ @g'`)
array_length=${#array[@]}

for ((i=${array_length};i>=0;i--))
do
 unset array[$i]
 SUBPWD=`echo " "${array[@]} | sed 's@ @/@g'`
 DISK=`df -h |grep ${SUBPWD}$ |awk '{print $1}'`
 [[ -n $DISK ]] && break
done

 

#Exit if it is not ext4 [[ "`mount |grep ${DISK} |awk '{print $5}'`" != "ext4" ]] && { echo ${DISK} is not mount on type ext4! Only ext4 file system support!;exit 2; }

debugfs -R "stat <${INODE}>" ${DISK}

use:

chmod +x statx
mv statx /usr/sbin/statx

[root@192-168-199-198 backups]# statx 2.txt
debugfs 1.42.9 (28-Dec-2013)
Inode: 14 Type: regular Mode: 0644 Flags: 0x80000
Generation: 737271740 Version: 0x00000000:00000001
User: 0 Group: 0 Size: 30
File ACL: 0 Directory ACL: 0
Links: 1 Blockcount: 8
Fragment: Address: 0 Number: 0 Size: 0
 ctime: 0x5d369644:211c1170 -- Tue Jul 23 13:08:20 2019
 atime: 0x5d36bb8f:56eb1e70 -- Tue Jul 23 15:47:27 2019
 mtime: 0x5d3691c7:6e5dbb68 -- Tue Jul 23 12:49:11 2019
crtime: 0x5d3691c7:6e5dbb68 -- Tue Jul 23 12:49:11 2019
Size of extra inode fields: 28
EXTENTS:
(0):35337

! ! ! Please use with caution in production environments. Shell scripts do not do much exception handling, do not support pipes, do not support directories, and have not been extensively tested.

In actual combat, we go back and use this method to confirm whether the "xtrabackup schematic" is accurate.

What we need to verify is:

xtrabackup_log is the first file created and the last file saved

1. Create a backup

DATE=`date "+%Y%m%d%H%M%S"`
xtrabackup -uroot -proot \
 -S /tmp/mysql3306.sock \
 --backup \
 --target-dir=/backups/$DATE

2. Find the crtime of all backup files

cd /backups/$DATE
>/tmp/1.txt
>/tmp/2.txt
find . -type f >/tmp/1.txt

for i in `cat /tmp/1.txt`
do
 { echo -n $i" ";statx $i 2>/dev/null |grep crtime |awk '{print $7}'; } >>/tmp/2.txt
done

cat /tmp/2.txt |sort -k2 |less
###The following is the output###
./ibdata1 23:32:59
./xtrabackup_logfile 23:32:59 #<---You can see that this file is the first one created./mysql/engine_cost.ibd 23:33:00
./mysql/gtid_executed.ibd 23:33:00
./mysql/help_category.ibd 23:33:00
./mysql/help_keyword.ibd 23:33:00
./mysql/help_relation.ibd 23:33:00
./mysql/help_topic.ibd 23:33:00
./mysql/innodb_index_stats.ibd 23:33:00
./mysql/innodb_table_stats.ibd 23:33:00
./mysql/plugin.ibd 23:33:00
./mysql/server_cost.ibd 23:33:00
./mysql/servers.ibd 23:33:00
./mysql/slave_master_info.ibd 23:33:00
./mysql/slave_relay_log_info.ibd 23:33:00
./mysql/slave_worker_info.ibd 23:33:00
./mysql/time_zone.ibd 23:33:00
./mysql/time_zone_leap_second.ibd 23:33:00
...
./zabbix/trigger_tag.frm 23:33:09
./zabbix/users.frm 23:33:09
./zabbix/users_groups.frm 23:33:09
./zabbix/usrgrp.frm 23:33:09
./zabbix/valuemaps.frm 23:33:09
./zabbix/widget_field.frm 23:33:09
./zabbix/widget.frm 23:33:09

3. Find the mtime of all backup files

>/tmp/1.txt
>/tmp/2.txt
find . -type f >/tmp/1.txt

for i in `cat /tmp/1.txt`
do
 { echo -n $i" ";statx $i 2>/dev/null |grep mtime |awk '{print $7}'; } >>/tmp/2.txt
done

cat /tmp/2.txt |sort -k2 |less
###The following is the output###
./ibdata1 23:33:00
./mysql/engine_cost.ibd 23:33:00
./mysql/gtid_executed.ibd 23:33:00
./mysql/help_category.ibd 23:33:00
./mysql/help_keyword.ibd 23:33:00
./mysql/help_relation.ibd 23:33:00
./mysql/help_topic.ibd 23:33:00
./mysql/innodb_index_stats.ibd 23:33:00
./mysql/innodb_table_stats.ibd 23:33:00
./mysql/plugin.ibd 23:33:00
...
./xtrabackup_logfile 23:33:09 #<---You can see that this file is the last modified and saved./zabbix/acknowledges.frm 23:33:09
./zabbix/actions.frm 23:33:09
...
./zabbix/users_groups.frm 23:33:09
./zabbix/usrgrp.frm 23:33:09
./zabbix/valuemaps.frm 23:33:09
./zabbix/widget_field.frm 23:33:09
./zabbix/widget.frm 23:33:09

Finally, we verified the correctness of the first and seventh steps of the xtrabackup schematic by looking at the creation and modification time of the files.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.

You may also be interested in: