浅谈Linux下通过find命令进行rm文件删除的小技巧
我们经常会通过find命令进行批量操作，如：批量删除旧文件、批量修改、基于时间的文件统计、基于文件大小的文件统计等，在这些操作当中，由于rm删除操作会导致目录结构变化，如果要通过find结合rm的操作写成脚本，就会遇到一些麻烦，本文通过一个例子为大家进行介绍。
系统环境：
SUSELinuxEnterpriseServer11或
RedHatEnterpriseLinux
问题症状：
客户现场有一个自动化的脚本，有以下的find语句，每天运行以删除某个目录下7天以前的文件或目录，这些目录都是按时间顺序生成PostgreSQL数据库的WAL日志及其错误日志pg_log：
/bin/find/enterprisedb_backup/postgresql/-mtime+7-exec/bin/rm-rf'{}'\;
运行过程中，间歇性地出现以下错误：
[root@edb~]#/bin/find/enterprisedb_backup/postgresql/-mtime+7-exec/bin/rm-rf{}\;
/bin/find:`/enterprisedb_backup/postgresql/network-scripts':Nosuchfileordirectory
[root@edb~]#echo$?
1
显然，以上命令返回了错误的结果，但客户反映说，以上脚本运行后目录下7天前的数据的确备删除了。
问题分析：
进行故障重现，在另一台服务器中通过模拟数据单独运行find命令分析此问题，测试过程如下：
1.模拟数据
[root@edbnode1~]#date WedJun1823:08:18CST2014 [root@edbnode1~]#cp-rcp/etc/sysconfig/network-scripts//enterprisedb_backup/postgresql/ [root@edbnode1~]#cp-rcp/etc/init.d/iptables/enterprisedb_backup/postgresql/##以上通过cp-rcp命令使得拷贝到目标目录的数据保持包括：建立时间、用户权根等信息，以模拟出一个旧文件及一个旧目录 [root@edbnode1~]#ll/enterprisedb_backup/postgresql/ total16 -rwxr-xr-x.1rootroot9409Oct312012iptables drwxr-xr-x.2rootroot4096Jun182013network-scripts##以上可以看到iptables文件是2012年建立的，network-scripts是2013年建立的，都远远超过了7天 [root@edbnode1~]#ll/enterprisedb_backup/postgresql/* -rwxr-xr-x.1rootroot9409Oct312012/enterprisedb_backup/postgresql/iptables /enterprisedb_backup/postgresql/network-scripts: total212 -rw-r--r--.1rootroot159Jun182013ifcfg-eth0 -rw-r--r--.1rootroot203Jun182013ifcfg-eth1 -rw-r--r--.1rootroot203Jun182013ifcfg-eth2 -rw-r--r--.1rootroot254Jan92013ifcfg-lo lrwxrwxrwx.1rootroot20Jun182013ifdown->../../../sbin/ifdown -rwxr-xr-x.1rootroot627Jan92013ifdown-bnep -rwxr-xr-x.1rootroot5397Jan92013ifdown-eth -rwxr-xr-x.1rootroot781Jan92013ifdown-ippp -rwxr-xr-x.1rootroot4168Jan92013ifdown-ipv6 lrwxrwxrwx.1rootroot11Jun182013ifdown-isdn->ifdown-ippp -rwxr-xr-x.1rootroot1481Jan92013ifdown-post -rwxr-xr-x.1rootroot1064Jan92013ifdown-ppp -rwxr-xr-x.1rootroot835Jan92013ifdown-routes -rwxr-xr-x.1rootroot1370Jan92013ifdown-sit -rwxr-xr-x.1rootroot1434Jan92013ifdown-tunnel lrwxrwxrwx.1rootroot18Jun182013ifup->../../../sbin/ifup -rwxr-xr-x.1rootroot12365Jan92013ifup-aliases -rwxr-xr-x.1rootroot859Jan92013ifup-bnep -rwxr-xr-x.1rootroot10157Jan92013ifup-eth -rwxr-xr-x.1rootroot11971Jan92013ifup-ippp -rwxr-xr-x.1rootroot10401Jan92013ifup-ipv6 lrwxrwxrwx.1rootroot9Jun182013ifup-isdn->ifup-ippp -rwxr-xr-x.1rootroot727Jan92013ifup-plip -rwxr-xr-x.1rootroot954Jan92013ifup-plusb -rwxr-xr-x.1rootroot2364Jan92013ifup-post -rwxr-xr-x.1rootroot4154Jan92013ifup-ppp -rwxr-xr-x.1rootroot1925Jan92013ifup-routes -rwxr-xr-x.1rootroot3499Jan92013ifup-sit -rwxr-xr-x.1rootroot2488Jan92013ifup-tunnel -rwxr-xr-x.1rootroot3770Jan92013ifup-wireless -rwxr-xr-x.1rootroot4623Jan92013init.ipv6-global -rwxr-xr-x.1rootroot1125Jan92013net.hotplug -rw-r--r--.1rootroot13079Jan92013network-functions -rw-r--r--.1rootroot29853Jan92013network-functions-ipv6 ##以上可以看到network-script不是一个空的目录，当中还有文件，而且文件也都已经是7天前建立的了
2.测试单独模拟执行脚本中的find+rm指令
[root@edbnode1~]#/bin/find/enterprisedb_backup/postgresql/-mtime+7-exec/bin/rm-rf{}\;
/bin/find:`/enterprisedb_backup/postgresql/network-scripts':Nosuchfileordirectory
[root@edbnode1~]#echo$?
1
[root@edbnode1~]#ls/enterprisedb_backup/postgresql/
[root@edbnode1~]#
可以看到find操作的确返回了错误的结果，但查看数据备份目录发现，iptables文件及network-scripts目录已经正确删除
3.由于数据已经正确删除，因此我们开始怀疑是由network-scripts目录删除后，find继续尝试删除此目录下其它文件，导致出不“Nosuchfileordirectory”的错误，因此需要于进一步证实此猜想，重新执行以上“第1步”中的数据环境模拟，并执行以下操作，主要是将rm转换成ls以展现整体运行过程：
[root@edbnode1~]#cp-rcp/etc/sysconfig/network-scripts//enterprisedb_backup/postgresql/
[root@edbnode1~]#cp-rcp/etc/init.d/iptables/enterprisedb_backup/postgresql/
[root@edbnode1~]#/bin/find/enterprisedb_backup/postgresql/-mtime+7-exec/bin/ls{}\;
ifcfg-eth0ifcfg-lo ifdown-ethifdown-isdnifdown-routesifup ifup-ethifup-isdnifup-postifup-sit init.ipv6-globalnetwork-functions-ipv6
ifcfg-eth1ifdown ifdown-ipppifdown-postifdown-sit ifup-aliases ifup-ipppifup-plipifup-pppifup-tunnelnet.hotplug
ifcfg-eth2ifdown-bnepifdown-ipv6ifdown-pppifdown-tunnelifup-bnep ifup-ipv6ifup-plusbifup-routesifup-wirelessnetwork-functions
/enterprisedb_backup/postgresql/network-scripts/ifup-plusb
/enterprisedb_backup/postgresql/network-scripts/ifup-sit
/enterprisedb_backup/postgresql/network-scripts/ifdown-post
/enterprisedb_backup/postgresql/network-scripts/ifcfg-lo
/enterprisedb_backup/postgresql/network-scripts/network-functions
/enterprisedb_backup/postgresql/network-scripts/ifup-bnep
/enterprisedb_backup/postgresql/network-scripts/ifup-ippp
/enterprisedb_backup/postgresql/network-scripts/ifdown-sit
/enterprisedb_backup/postgresql/network-scripts/ifdown-tunnel
/enterprisedb_backup/postgresql/network-scripts/ifup-plip
/enterprisedb_backup/postgresql/network-scripts/ifup-eth
/enterprisedb_backup/postgresql/network-scripts/ifdown-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifdown-ippp
/enterprisedb_backup/postgresql/network-scripts/ifup-aliases
/enterprisedb_backup/postgresql/network-scripts/network-functions-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifup-ipv6
/enterprisedb_backup/postgresql/network-scripts/ifup-post
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth2
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth1
/enterprisedb_backup/postgresql/network-scripts/ifdown-ppp
/enterprisedb_backup/postgresql/network-scripts/ifup-isdn
/enterprisedb_backup/postgresql/network-scripts/ifcfg-eth0
/enterprisedb_backup/postgresql/network-scripts/ifdown
/enterprisedb_backup/postgresql/network-scripts/ifup-wireless
/enterprisedb_backup/postgresql/network-scripts/ifup-ppp
/enterprisedb_backup/postgresql/network-scripts/ifdown-eth
/enterprisedb_backup/postgresql/network-scripts/init.ipv6-global
/enterprisedb_backup/postgresql/network-scripts/ifdown-isdn
/enterprisedb_backup/postgresql/network-scripts/ifup-tunnel
/enterprisedb_backup/postgresql/network-scripts/ifdown-routes
/enterprisedb_backup/postgresql/network-scripts/ifdown-bnep
/enterprisedb_backup/postgresql/network-scripts/net.hotplug
/enterprisedb_backup/postgresql/network-scripts/ifup
/enterprisedb_backup/postgresql/network-scripts/ifup-routes
/enterprisedb_backup/postgresql/iptables
通过以上操作我们可以看到，find命令不单查询了/enterprisedb_backup/postgresql/目录，并且遍历了所有子目录，因此支持了我们的推断
4.综上所述基本定位问题所在
解决方案：
1.整理思路后，可以确认，如果find只找出所需操作目录的第1层文件及目录即可解决此问题
2.通过伟大的man命令我们得到以下信息
-maxdepthlevels Descendatmostlevels(anon-negativeinteger)levelsofdirectoriesbelowthecommandlinearguments.-maxdepth0meansonlyapplythetestsandactionstothecommandlinearguments.
3.测试操作确认修改为：
[root@edbnode1~]#/bin/find/enterprisedb_backup/postgresql/-mtime+7-maxdepth1-exec/bin/rm-rf{}\;
/bin/find:warning:youhavespecifiedthe-maxdepthoptionafteranon-optionargument-mtime,butoptionsarenotpositional(-maxdepthaffectstestsspecifiedbeforeitaswellasthosespecifiedafterit).Pleasespecifyoptionsbeforeotherarguments.
这里意思是说：-mtime找到的信息可能会操过-maxdepth的范围，在find操作中建议-maxdepth放在所有其他参数的前面
解决结果【完成】
以上这篇浅谈Linux下通过find命令进行rm文件删除的小技巧就是小编分享给大家的全部内容了，希望能给大家一个参考，也希望大家多多支持毛票票。