Bug 450870

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.