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 ). How reproducible: Always Steps to Reproduce: 1. Run tmpwatch on a directory and delete nothing 2. Run ll --time=ctime 3. 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. Additional info: 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) system call. 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 standards.