Bug 450871 - tmpwatch mis-handles -m parameter on NFS shares (causes data loss)
tmpwatch mis-handles -m parameter on NFS shares (causes data loss)
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: tmpwatch (Show other bugs)
rawhide
All Linux
low Severity urgent
: ---
: ---
Assigned To: Miloslav Trmač
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-11 10:42 EDT by Robert Scheck
Modified: 2008-06-11 11:15 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-11 11:15:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2008-06-11 10:42:36 EDT
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.13-2

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:
This bug report is the same for Fedora as bug #450870 is for RHEL 5 as latest
tmpwatch doesn't fix this bug as well.
Comment 1 Robert Scheck 2008-06-11 11:15:12 EDT
Okay, this is not the same bug report, it's just my dumbness here. My check using 
latest tmpwatch was too lazy, stat(1) showed my failure here. Sorry for bothering 
- and thanks for your suggestion in IRC.

Note You need to log in before you can comment on or make changes to this bug.