Bug 51325 - Incorrectly modifies ctime of directory entry
Incorrectly modifies ctime of directory entry
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: tmpwatch (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Preston Brown
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-09 10:55 EDT by Dave J
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-09 10:55:19 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 Dave J 2001-08-09 10:55:15 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 ).



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.
Comment 1 Preston Brown 2001-08-13 15:40:52 EDT
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.

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