Linux下查找修改和新增文件：find、git与inotify完整指南

接手一台跑着旧业务的服务器老板只扔过来一句“这几天好像有人动过文件你去看看到底改了啥”。这种需求听着简单真干起来几乎每个人都会在第一步卡住到底该用什么命令才能在几百万个文件里把“修改过”和“新增进来”的文件准确挑出来我这些年处理过不少类似情况从代码发布前的变更清单到备份前先确认增量文件再到系统异常排查核心问题其实都是同一个——查找修改和新增的文件。这篇文章把我反复验证过的几种方法和踩过的坑一起写出来希望能让你少走点弯路。1. 先搞清楚“找文件”到底是给谁看的1.1 三种常见需求对应的工具其实完全不同同样是找修改和新增的文件落在不同场景里目标文件、判断依据、可用的工具都不一样。我一般把需求分成三类先分清是哪一类再动手。第一类是代码发布场景。你准备上线一个新版本老板问“这次到底改了哪些文件”这时候你手里有完整的版本库git status、git diff是最直接的工具根本不需要跑到磁盘上去翻时间戳。第二类是备份和同步场景。你想把某个目录增量备份到另一台机器前提是要知道最近一段时间哪些文件变了这类需求通常会落到find的时间戳参数上或者用同步工具自带的 dry-run 模式。第三类是异常排查场景。你怀疑有人动了系统文件或者某个目录里混进了不该出现的东西这时候不但要找出变动的文件还要分辨哪些是正常的、哪些是可疑的通常会组合使用find、stat、file、sha256sum这几条命令。这三类需求如果混在一起用同一种方法很容易出问题。比如你明明是代码场景却去翻磁盘找 mtime就会把node_modules里几百个无关文件全部报上来反过来你明明是备份场景却非要用 git 去查结果发现目标目录压根不是 git 仓库。所以开头这个分类动作能帮你在后面节省大量时间。1.2 动手之前先确认你面对的文件系统提供了哪些线索无论用哪种方法找到“修改”和“新增”都要依赖文件系统留下的线索。Linux 下最常用的线索是时间戳但很多新手不知道Linux 的 stat 信息里并没有一个统一的“创建时间”字段。拿我自己的习惯来说开工前通常先对目标文件跑一条stat命令看系统到底给了多少信息$ stat /srv/www/index.php File: /srv/www/index.php Size: 2048 Blocks: 8 IO Block: 8192 regular file Access: 2025-01-09 10:00:00.000000000 0800 Modify: 2025-01-10 14:23:55.000000000 0800 Change: 2025-01-10 14:23:55.000000000 0800 Birth: 2025-01-06 09:12:00.000000000 0800这里Access是访问时间Modify是内容最后被修改的时间Change是文件状态权限、属主、硬链接等发生变化的时间后面的Birth才是真正的创建时间。问题在于Birth只有在特定的文件系统和内核版本下才会显示不少老内核、老工具根本取不到这个值甚至不同的挂载方式下结果都不一样。所以实际工作中我很少依赖“创建时间”而是换一种等价的思路如果文件系统无法直接告诉我“哪个文件是今天新增的”我就反过来查“哪个目录今天被新增了文件”——文件一旦放进某个目录目录的Modify时间就会被更新顺着这个线索往往可以定位到新增文件所在的位置。还要确认文件系统类型。如果你处理的是 NFS、CIFS 这类网络文件系统时间戳精度和更新策略都可能跟本地磁盘不一样有的甚至会整体偏移几个小时直接用find -mtime找出来的文件会不准确。这种情况下我会优先考虑内容哈希快照或者改用同步工具的增量列表而不是死磕本地时间戳。2. 靠时间戳找文件find 命令的真正用法2.1 Linux 时间戳三兄弟别再傻傻分不清find命令里最常用的三个参数是-atime、-mtime、-ctime分别对应访问时间、修改时间和状态改变时间。很多人看了一遍文档就开跑结果经常把-mtime和-ctime搞混最后拿到的文件清单完全不是自己要的。简单说文件内容被写入时mtime和ctime会一起变但是chmod、chown、创建硬链接这类操作只会改变ctime不会动mtime。如果你关心的是“文件内容有没有被改”那就看mtime如果你关心的是“文件的元信息有没有被动过”那就看ctime。还有一个atime只要有人读取文件它就可能变更在现代 Linux 默认的relatime挂载参数下访问时间不会频繁更新但如果你刻意去cat一个文件它还是有很大概率会变。所以排查异常时atime只能作为辅助参考不能当作主要依据。我个人最常用的还是mtime因为它最接近普通人理解的“这个文件什么时候被改动过”。至于新增文件在没有可靠Birth时间的情况下通常退而求其次用“文件的 mtime 落在某个时间窗口内”来近似判断。一个文件如果是刚生成的它的 mtime 必然是当前时间附近反过来如果某天系统被重新部署过大量文件的 mtime 会被统一刷新成那天的时间这个现象本身就是很有价值的排查线索。2.2 一套可以直接抄作业的 find 指令组合下面这些命令我基本每天都在用全部基于mtime配合-type f只查文件、不查目录配合-printf把时间戳和完整路径一起打出来。查找最近 24 小时内被修改过内容的所有普通文件find /srv/www -type f -mtime -1 -printf %TY-%Tm-%Td %TH:%TM %p\n-mtime -1表示“小于 1 天”注意这里不是“1 天之内”这么简单find的计算单位是 24 小时按当前时间往前推。如果你只想看最近 10 分钟的情况用-mmin -10更精确find /srv/www -type f -mmin -10 -printf %TY-%Tm-%Td %TH:%TM %p\n想找某个明确时间点之后新增或修改的文件-newermt是最好用的参数不需要先建一个临时文件来做比较对象find /srv -type f -newermt 2025-01-10 00:00:00 -printf %TY-%Tm-%Td %TH:%TM %p\n反过来想查某段时间之前的旧文件用叹号取反find /srv -type f ! -newermt 2024-06-01 -printf %TY-%Tm-%Td %TH:%TM %p\n如果文件特别多希望按时间从新到旧排列可以把时间戳里的%T从纪元开始的秒数取出来排序find /srv/www -type f -mtime -7 -printf %T %p\n | sort -rn | head -50这样就能快速看到最近一周之内最靠前的 50 个变动文件。我建议你把这组命令存成一个脚本文件后面加个参数接收目录和时间窗口这样每次要用的时候直接调用比自己临时拼字符串稳妥得多也能避免漏掉参数导致全盘扫描。2.3 一个容易翻车的细节目录的 mtime 会骗人很多人在第一次用find找“新增文件”时会顺手把目录也列出来。要知道文件的内容一旦被修改目录本身的 mtime 并不会变化但如果你往目录里新增或删除了一个文件目录的 mtime 就会被刷新。换句话说如果你看到一个目录的 mtime 很新这只能说明最近有文件被“放进来”或“移出去”并不能直接说明目录里的文件内容有变动。反过来如果你只是想快速定位“新增文件集中在哪个目录”我可以先找出 mtime 变动的目录再进入目录去细查文件。比如find /srv -type d -mmin -30 -print这一步能缩小范围但千万别把它当成最终结论。我遇到过的情况是某台机器上部署脚本每晚都会往临时目录里写日志导致/srv/log/tmp这类目录的 mtime 永远都是新的如果直接拿目录 mtime 做判断就会把大量正常目录误报成“可疑变更”。正确的姿势永远是目录时间戳只负责缩小范围最终结论一定要落到具体文件上。还有一个在递归查找时必须注意的点符号链接。默认情况下find不会跟着符号链接跳转如果你被查找的目录里放了指向系统重要目录的软链漏报就是这样发生的。需要追踪链接时改用-L参数但代价是可能跳出你原本想限制的目录范围甚至把/etc、/usr下的文件也带进来。所以要时刻清楚自己到底需不需要跟软链。3. 版本控制里的变更查找git 比 find 更靠谱3.1 代码场景用 git 的核心理由它知道文件的全部历史如果你的工作目录是一个 git 仓库那我强烈建议不要用find去查“最近改动过哪些文件”。原因很简单find只能看到当前磁盘上的时间戳状态而 git 记住的是每次提交的内容差异包括文件被重命名、被改回旧版本、被删除又重新加回来这些复杂操作。这些在时间戳层面几乎没法看但 git 里只是一条记录的事。举例来说你前一天 checkout 了一个旧分支会把一大片文件的 mtime 全部刷新到当天。这时候如果用find -mtime去找“今天改过的文件”会得到上百个文件里面绝大多数只是被 checkout 刷了时间戳内容根本没变。而用git status它会通过内容的哈希对比直接告诉你有几个文件真改了干干净净不掺一点水分。3.2 从命令到清单git status、git diff 和 git log 的配合我先说自己最常用的一套流程。第一步永远是git status这是最快的总览git status --short输出里的M表示文件被修改A表示新增D表示删除??表示未被跟踪的新文件。如果只想看纯文件清单配合git diff --name-status会更灵活# 查看工作区相对暂存区的改动 git diff --name-status # 查看暂存区相对 HEAD 的改动 git diff --cached --name-status # 查看某个提交到当前的所有改动 git diff --name-status HEAD~1..要单独挑出“新增文件”可以加--diff-filterAgit diff --name-status --diff-filterA HEAD~1..要查“最近两天新增或修改了哪些文件”用git log更直观git log --since2 days ago --name-status --oneline --prettyformat:%h %ad %s --dateshort这条命令会把最近两天内的提交哈希、提交时间、说明和每个文件的状态全部打印出来非常适合发布前做变更评审。我会把输出重定向到文件里按提交逐个核对最后汇总成一份“本次发布涉及文件清单”比手工翻目录快了不知道多少倍。3.3 没纳入 git 管理的文件才是隐藏的雷git status里的??表示未被跟踪文件但如果你用了.gitignore里面排除掉的文件不会出现在??列表里可能漏掉一些实际上已经新增进目录的文件。要完整列出“所有未被 git 跟踪的新文件”我用的是git ls-files --others --exclude-standard这条命令会列出所有未跟踪文件同时自动忽略.gitignore中规则的干扰。反过来如果你想列出“虽然被 .gitignore 忽略但实际存在于磁盘上”的文件可以去掉--exclude-standard。这里有个坑很多人拿到一个解压出来的项目目录里面根本没有.git文件夹这时 git 命令全都会失效。遇到这种情况我会先问一句“这个目录有没有版本管理”如果确实没有那就只能回到find的时间戳方案同时提醒对方以后最好先把目录初始化成 git 仓库否则“查找修改和新增的文件”永远只能靠猜。4. 服务器上排查可疑新增文件的实战思路4.1 从时间窗口到完整命令一次标准的可疑文件扫描服务器排查和普通目录查找的最大区别在于你没有现成的“文件清单”可以依赖只能靠时间窗口来圈定范围。假设你从系统日志里看到某个服务在昨天 22:00 左右出现了异常重启想查一下那个时间点前后有没有文件被动过我会这样组装命令find / \ -xdev \ -type f \ -newermt 2025-01-10 21:45:00 \ ! -newermt 2025-01-10 23:00:00 \ -printf %TY-%Tm-%Td %TH:%TM:%TS %s %p\n \ -print 2/dev/null | sort -k1,2这里有几个参数非常关键。-xdev表示只在当前文件系统内查找避免把/proc、/sys、/dev这些虚拟文件系统也扫进来-type f保证结果里只有普通文件-newermt和! -newermt组合成一个精确的时间窗口-printf把修改时间、文件大小和路径同时输出方便后续按时间和大小排序最后的2/dev/null是为了屏蔽掉大量没权限访问目录的报错让结果干净一些。如果想同时照顾到“可能存在新增文件但位置很偏”的情况我会把整个根分区都扫一遍。但这会非常耗时所以我会先用前面那种缩时间的写法跑一轮把结果存成文本再针对可疑目录做第二轮深度查找。切忌一次性让全盘扫出几百个文件那样只会扰乱视线。4.2 看到结果后怎么判断哪个文件可疑拿到 find 的结果只是第一步真正费工夫的是从中挑出值得重点关注的异常项。我总结过几条识别信号发现命中越多越值得警惕。第一是位置信号。正常业务文件通常待在/srv、/var/www、/opt之类的业务目录里如果扫描结果里出现/tmp、/var/tmp、/dev/shm、/var/spool/cron这些目录下的新文件就要格外留个心眼。第二是扩展名和类型信号。用file命令逐个确认可疑文件到底是什么格式file /tmp/abc.sh如果文件名看着像日志file却告诉你这是一个可执行的 ELF 二进制或者是一个被压缩过的脚本那肯定有问题。第三是权限信号。正常文件权限通常遵循业务规范-rw-r--r--或-rw-r-----居多如果看到一个普通文件变成-rwxrwxrwx或者被加了 setuid 位建议直接记到重点清单里。还要注意隐藏文件。很多人在第一步扫描时会把隐藏文件漏掉因为它们的路径里带了.而且默认的find并不会忽略隐藏文件但如果你的命令里加了-not -path */.*那就会把最重要的线索排除掉。所以在排查场景我不会做这种排除反而会额外加一条find / -xdev -type f -name .* -mmin -30 -printf %TY-%Tm-%Td %TH:%TM %p\n4.3 锁定了文件之后保留现场比直接动手更重要一旦发现几个高度可疑的文件我的建议是先别急着删除或编辑而是把现场保留下来再做证据固定的操作。具体的做法是这样先用stat看完整时间戳再用sha256sum记录内容哈希最后把原文件复制到一个只读目录里存档mkdir -p /tmp/evidence_20250110 cp -a /tmp/abc.sh /tmp/evidence_20250110/ sha256sum /tmp/abc.sh /tmp/evidence_20250110/hashes.txt stat /tmp/abc.sh /tmp/evidence_20250110/stat.txt之所以这么强调保留现场是因为很多“看似可疑”的文件最后可能只是某个维护脚本产生的中间产物。如果你手一快删掉了后续一旦要回溯就彻底没了依据。等证据固定完毕再去检查对应服务的日志和启动配置确认这个文件到底是被谁、在什么时间、通过什么入口引入的。5. 文件变动实时监控与自动化清单5.1 inotifywait 入门监听 create、modify、delete 三类事件如果“查找修改和新增的文件”对你来说是高频需求比如你需要随时知道某个业务目录下发生了什么变化那与其等事后扫描不如装一个实时监控。Linux 内核自带的 inotify 机制就是干这个的通常会在inotify-tools包里。Debian/Ubuntu 系统安装并监听目标目录sudo apt install inotify-tools inotifywait -rm \ --timefmt %Y-%m-%d %H:%M:%S \ --format %w%f %e %T \ -e create,modify,delete,attrib \ /srv/www这里的-r是递归-m是持续监控-e指定要关注的事件类型create对应新增文件modify对应内容修改delete对应删除attrib对应权限或属主变化。一次跑起来后终端会持续输出事件信息例如/srv/www/config/app.php MODIFY 2025-01-10 14:23:55 /srv/www/log.php CREATE 2025-01-10 14:26:02这套方案非常适合用来补齐“查新增文件无法依赖创建时间”的短板。只要监控是提前部署好的每次文件一出现就会被第一时间记录下来事后想追溯只需要翻监控日志。不过它有个硬限制inotify 默认的监听数量不是无限的如果目录树太大你会遇到“设备上没有空间”之类的报错。这种情况下需要调高内核参数sudo sysctl fs.inotify.max_user_watches524288 sudo sysctl fs.inotify.max_user_instances1024另外NFS、CIFS 这类网络文件系统不支持 inotify所以它只适合监听本地磁盘上的真实目录。别指望挂载在远程的共享目录也能触发事件。5.2 定时快照比对没有实时监控也能实现增量查找如果你的机器不方便安装新组件或者只想低频地做日结快照比对也是个可靠方案。核心思路是定期生成一份文件清单两次清单做对比找出新增和发生变化的行。最朴素的清单是用 find 记录每个文件的路径、修改时间和大小find /srv/www -type f -printf %p|%T|%s\n | sort snapshot_$(date %Y%m%d).txt之后再用 diff 对比今天和昨天的快照diff snapshot_20250109.txt snapshot_20250110.txt如果只关心文件内容到底变没变单看 mtime 不够严谨因为touch可以伪造时间戳。更严格的做法是计算完整内容哈希find /srv/www -type f -exec sha256sum {} \; | sort -k2 snapshot_hashes_$(date %Y%m%d).txt代价是扫描大目录会比较慢但准确性比其他方式都高。我自己在管理一台存储业务数据的机器时每天凌晨跑一次全量哈希快照再 diff 出清单排查问题的时候直接翻清单就好根本不用临时扫描。5.3 增量备份场景下找出“会变化的文件”其实有捷径做增量备份时我们通常不关心文件具体改了多少字节只想知道“哪些文件需要重新传输”。这时候 rsync 的 dry-run 模式是现成的答案生成器rsync -av --dry-run /srv/www/ /backup/www/加上--dry-runrsync 不会真的复制文件只会列出它打算传输的文件清单。输出的每一行都是一个需要从源端同步过去的新增或修改文件比自己在 find 里折腾时间窗口快多了。如果你还想把删除的文件也标出来加一个--delete --itemize-changes输出里就能看到每个文件的类型标记f是普通文件d是目录表示内容需要更新。如果网络环境有限不想跑 rsync还有一个基于 find 的经典小技巧创建一个固定时间戳的标记文件作为时间窗口的参考点touch -d 2025-01-10 00:00:00 /tmp/incremental_marker find /srv/www -type f -newer /tmp/incremental_marker -print这种方式简单直接适合脚本里临时用。不过我提醒一句-newer markfile比较的是标记文件的 mtime如果这个标记文件后来被别人 touch 过整个时间窗口就毁了。所以脚本里的标记文件路径最好放到临时目录并且在每次执行后重新 touch。6. 我在实操里反复踩过的几个坑6.1 从备份恢复后mtime 会全线刷新别被误导有一次我在某台机器上从 tar 包恢复了一批文件然后按惯例用find -mtime -1查找“今天新增的文件”结果一下子冒出来几千个文件——全是我自己刚恢复进去的。原因是 tar 恢复时如果没加-m选项文件时间会被恢复成包内保存的时间但如果对方打包时本身就没记录时间戳或者用的命令带了-m恢复出来的文件 mtime 就会变成当前时间。这时候你要找的“新增文件”其实是整个目录被覆盖过的痕迹不是真正的文件级新增。遇到这种情况比较靠谱的做法是拉出备份包里的原始清单做比对而不是依赖磁盘时间戳。如果你只有磁盘可以用内容哈希对可疑目录做两轮对比把时间戳的影响降到最低。6.2 find -newer 的比较对象选错漏斗直接失效find -newer不是只能传文件也可以传目录。但目录的 mtime 代表的是目录内文件的增删情况不代表每个子文件都变了。如果你拿一个 mtime 很新的目录作为比较基准再用-newer去筛子文件可能会漏掉真正有问题的文件——因为目录时间戳可能只是被一个临时文件刷新了而已。我后来几乎不用-newer加“实时创建的文件”这种方式而是改成直接在命令行里写死-newermt 2025-01-10 00:00:00。这样比较基准明确、可审计别人看你脚本的时候一眼就能明白时间窗口在哪里。6.3 扫描时没排除挂载点和虚拟文件系统误报能笑死人find /看起来是把全盘都扫了但它同时也会把/proc、/sys、/dev这些虚拟目录一起遍历。这些目录下的文件很多是内核参数或设备文件它们的 mtime 一直在动态变化扫出来的结果几乎全是噪音。我第一次这么做时清单里全是/proc下的数字路径吓一跳之后才想起来自己忘了加-xdev。正确的做法是在大型扫描命令里同时加上-xdev和-path /proc -prune这类排除项把虚拟文件系统和跨分区的挂载点全部挡在门外。如果你确实需要横向扫描多个磁盘分区可以分别对每个分区单独跑命令最后合并结果。6.4 大目录扫描极慢先缩小范围再跑命令一个含上百万文件的大目录纯粹用find -mtime全量遍历可能要跑几十分钟这种等待非常痛苦。我的优化习惯是先用目录 mtime 缩小到可能包含新文件的子目录或者直接用git ls-files这类已知清单缩小范围实在绕不开全盘扫描就改用fd这类并发遍历工具。fd默认会读取.gitignore跳过隐藏目录配合时间筛选参数也能完成类似工作而且实际体验明显快不少。6.5 文件名里的空格和换行会把所有脚本搞崩最后一个坑比较低级但非常常见文件名含空格或者特殊字符。直接用find加xargs处理时空格会让命令被拆成两截造成找不到文件或误删除的风险。规避办法是使用-print0和-0配对find /srv/www -type f -mtime -1 -print0 | xargs -0 -I {} ls -l {}所有需要把 find 结果传给其他命令的场景我都建议默认套上-print0这只是多写几个字符的事却能让脚本健壮一大截。最后再分享一个我自己的个人习惯不管是哪种查找方式完成之后我都会把命令、时间窗口和结果清单一起归档成一个文本文件放在固定的日志目录里。这样做一方面方便下次回溯“某个文件到底是什么时候出现的”另一方面也让整个查找过程变得有据可查被问到的时候能直接拿证据说话。这比临时手敲一条命令、看完就忘要靠谱得多。