Red Hat Bugzilla – Bug 51325
Incorrectly modifies ctime of directory entry
Last modified: 2007-04-18 12:35:40 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
Running tmpwatch on a directory changes ctime on the directory even if it
does nothing ( ie deletes nothing ) in the directory ( or subdirectories ).
Steps to Reproduce:
1. Run tmpwatch on a directory and delete nothing
2. Run ll --time=ctime
Actual Results: ctime on directory entries in top level directory ( from
where tmpwatch was acting ) are updated to time tmpwatch was run.
Expected Results: ctime stays same.
If tmpwatch changes ctime, then it won't ever delete directory unless time
to delete is less than interval tmpwatch is run ie if set up to delete on
ctime > 7 days, and tmpwatch is run every day, then ctime will get updated
every day, hence directory would never get deleted.
The mtime for a file or directory is updated by the filesystem each time the
file is modified. Prior to modifying a file, an application can save the
file's mtime, and then reset it after the modification using the utime(2)
The atime for a file or directory is updated by the filesystem each time the
file is accessed (read or write). Prior to accessing a file, an application
can save the file's atime, and then reset it after the file access using the
utime(2) system call.
The ctime for a file or directory is updated each time the file or directory's
inode is changed; examples of this are changing permissions, ownership,
link-counts, etc. The ctime for a file or directory can NOT be saved before
and reset after a change. Another significant fact is that the ctime of a file
or directory is CHANGED when resetting the mtime and atime (using the utime(2)
system call) for the file.
When tmpwatch reads the data for a file to determine whether or not it should
be removed, it does not affect the file modification time, but does affect the
file's access time. For this reason, NetBackup saves the file's atime and
mtime prior to reading the file, and resets the atime and mtime
using the utime(2) system call. By "covering it's tracks", tmpwatch does not
cause grief for HSM products or administrator scripts that are utilizing file
access times (atime) as criteria for their operations. While this benefit is
obvious, a side effect is that it does update the file's ctime.
There is no way around this while maintaining compatibility with UNIX