linux下获取文件的创建时间与实战教程

背景

有时候我们需要获取文件的创建时间。

例如:

我在研究 《xtrabackup 原理图》的时候,想通过观察确认 xtrabackup_log 是最早创建 并且是 最晚保存的文件。我们就需要知道 xtrabackup_logfile 这个文件的创建时间戳和修改时间戳。

复习: Linux关于文件的三个时间戳

Linux 的文件系统保存有三个时间戳,利用 stat 指令查看文件信息可以获取。他们分别是 ATime、MTime 和 CTime

[root@192-168-199-198 backups]# stat 2.txt 
 File: ‘2.txt'
 Size: 16   Blocks: 8   IO Block: 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 ——文件的最近访问时间

只要读取文件,ATime 就会更新,对应的是 stat 命令获取的 Access 的值。

[root@192-168-199-198 backups]# cat 2.txt #<-- 读取文件
121231233123123
[root@192-168-199-198 backups]# stat 2.txt 
 File: ‘2.txt'
 Size: 16   Blocks: 8   IO Block: 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:12:41.415980158 +0800
Change: 2019-07-23 12:12:41.415980158 +0800
 Birth: -

MTime ——文件的内容最近修改的时间

当文件进行被写的时候,CTime 就会更新,对应的是 stat 命令获取的 Modify 的值。

[root@192-168-199-198 backups]# echo hello_world > 2.txt #<-- 修改文件内容
[root@192-168-199-198 backups]# stat 2.txt 
 File: ‘2.txt'
 Size: 12   Blocks: 8   IO Block: 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 #<-- 时间变化了
Change: 2019-07-23 12:26:23.466953503 +0800
 Birth: -

这里不要用vi修改文件内容,因为用vi修改文件内容有可能会引起Inode变更,也就是你观察的文件并不是之前的文件了!这个和vi的原理有关。

CTime ——文件属性最近修改的时间

当文件的目录被修改,或者文件的所有者,权限等被修改时,CTime 也就会更新,对应的是 stat 命令获取的 Change 的值。

[root@192-168-199-198 backups]# chmod 777 2.txt #<-- 修改文件属性
[root@192-168-199-198 backups]# stat 2.txt 
 File: ‘2.txt'
 Size: 12   Blocks: 8   IO Block: 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 #<-- 时间变化了
 Birth: -

Linux 无法获取文件创建时间?

现在我们知道了Linux有三种时间,ATime、MTime 和 CTime,那么很好奇为什么没有 CRTime (创建时间) 呢?

对比 Windows 系统 (上图),Windows 的 NTFS 文件系统里存在三个时间戳,其中就包含了“创建时间”,但在 Linux 的设计哲学上没有文件“创建时间”这么一说,所以早期版本的ext文件系统不支持文件“创建时间”。但从 ext4 版本开始,文件创建时间存储在ext4文件系统的inode中,所以 ext4 文件系统使用特殊方法也是可以获取文件的创建时间的。

也说明了,是否能获取文件的创建时间,和文件系统是否支持有关。

Linux 上获取文件创建时间的步骤

CentOS7 Linux系统自带一个工具,叫做 debugfs,他可以查出 ext4 文件系统上的文件的创建时间。man debugfs 发现工具的描述是 “ext2/ext3/ext4 file system debugger”,所以他是不支持 xfs 文件系统的。

常用的 xfs 文件系统是否支持获取文件创建时间,还有如何获取,这个暂时不清楚,需读者查阅官方文档

1. 获取文件的 inode 号

方法一:

[root@192-168-199-198 backups]# stat /backups/2.txt
 File: ‘/backups/2.txt'
 Size: 30   Blocks: 8   IO Block: 4096 regular file
Device: 821h/2081d Inode: 14 #<--- 这个  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: -

方法二:

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

这里,我们获取的 inode 编号是 14。

2. 查找文件所在磁盘路径

[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  #<--- 可以看出文件在这里面
/dev/sda1        1014M 142M 873M 14% /boot
tmpfs          781M   0 781M  0% /run/user/0

磁盘路径为 /dev/sdc1

3. 使用debugfs 查看文件创建时间

[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

获取文件创建时间的脚本

鉴于获取文件创建时间步骤操作有点麻烦 (虽然只有三步 :) )

我这里提供了一个脚本

vi statx

#!/bin/sh

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

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

#如果传入参数带/,则获取这个传入参数的目录路径并进入目录
 `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

 

#不是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}

使用:

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

!!!请谨慎在生产环境使用,shell脚本没有做太多的异常处理,不支持管道,不支持目录也没有经过大量的测试

实战
我们回过头来,用这个方法,确认《xtrabackup 原理图》是否准确。

我们需要验证的是:

xtrabackup_log 是最早创建 并且是 最晚保存的文件

1. 创建备份

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

2. 查找所有备份文件的crtime

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
###以下为输出###
./ibdata1 23:32:59
./xtrabackup_logfile 23:32:59 #<---可以看出这个文件是最早创建的
./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. 查找所有备份文件的mtime

>/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
###以下为输出###
./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 #<---可以看出这个文件是最后修改和保存的
./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

最后,我们通过文件的创建时间和修改时间,实战地验证了《xtrabackup 原理图》的第一和第七步顺序的正确性。

总结

本篇文章到此结束,如果您有相关技术方面疑问可以联系我们技术人员远程解决,感谢大家支持本站!

香港服务器首选树叶云,2H2G首月10元开通。
树叶云(shuyeidc.com)提供简单好用,价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/189858.html<

(0)
管理的头像管理
上一篇2025-03-31 09:40
下一篇 2025-03-31 09:42

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注