Description of problem: I've two servers, 192.168.1.2 which exports /backup with read-write permissions into the network and 192.168.1.1 which imports/mounts /backup on local /backup to put backup files on it. After the backup files were put via NFS onto /backup, tmpwatch -a -m 7d /backup/<directory> is executed. As per man page, everybody would expect the files to be deleted after 7 days after last modification date. In fact the files are already deleted after ~ 6 hours - so tmpwatch mis-handles the -m parameter on NFS shares which causes unwished massive data loss. Reproducer for me: /backup/test is on an NFS share - both servers are fully up2date RHEL 5, have same time zone and are synced via NTP to exactly the same time. [root@intranet test]# date Wed Jun 11 16:35:38 CEST 2008 [root@intranet test]# [root@intranet test]# touch -t 200806111000 test [root@intranet test]# [root@intranet test]# ls -l total 4 -rw-r--r-- 1 root root 0 Jun 11 10:00 test [root@intranet test]# [root@intranet test]# tmpwatch -a -m 7d /backup/test/ [root@intranet test]# [root@intranet test]# ls -l total 4 -rw-r--r-- 1 root root 0 Jun 11 10:00 test [root@intranet test]# [root@intranet test]# touch -t 200806110900 test [root@intranet test]# [root@intranet test]# ls -l total 4 -rw-r--r-- 1 root root 0 Jun 11 09:00 test [root@intranet test]# [root@intranet test]# tmpwatch -a -m 7d /backup/test/ [root@intranet test]# [root@intranet test]# ls -l total 0 [root@intranet test]# [root@intranet test]# date Wed Jun 11 16:36:05 CEST 2008 [root@intranet test]# OUCH! What the fuck happens here? Version-Release number of selected component (if applicable): tmpwatch-2.9.7-1.1.el5.1 How reproducible: Everytime, see above. Actual results: tmpwatch mis-handles -m parameter on NFS shares (causes data loss) Expected results: Same behaviour for NFS shares as for local disks without data loss. Additional info: Even not fixed in latest tmpwatch-2.9.13-2 from Fedora Rawhide.
Thanks for your report. The 'd' suffix is supported only in tmpwatch-2.9.8, post-rhel5. So this appears to be "only" a missing diagnostic. Does tmpwatch behave correctly if you specify "168" instead of "7d"?
You're fully right - sorry, my mistake.
Please close as NOTABUG, because I'm not allowed to do so for my own bug report.