Bug 51325 - Incorrectly modifies ctime of directory entry
Summary: Incorrectly modifies ctime of directory entry
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tmpwatch   
(Show other bugs)
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Preston Brown
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-09 14:55 UTC by Dave J
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-09 14:55:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Dave J 2001-08-09 14:55:15 UTC
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 19:40:52 UTC
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.