find

[Chris Torek]

>In article <21231 at mimsy.umd.edu> I wrote:
>>`ctime' can be thought of as `time of last operation that requires that
>>the file be backed up'.  A backup program can decide whether a file needs
>>saving by comparing the file's ctime with the time of the previous backup.

In article <1917 at crdos1.crd.ge.COM> davidsen at crdos1.crd.ge.COM
(Wm E Davidsen Jr) writes:
>  No. ctime is the time of a change to the *inode* not the file.

I stand by my statement.  Your second sentence is correct if you change
the last three words to `or contents of the file'.  (Note that the inode
*is* the file, in some sense, so `inode, not file' is self-contradictory.)

>A smart backup program can just save the new inode info and restore that,
>if incremental dumps are being done. As an example, if you change the
>access with chmod, the inode time will change, and ctime will be
>updated. Since the content of the file has not changed the actual file
>itself doesn't need to be backed up.
>
>  The only backup which appears to take advantage of this is "dump," and
>I'm not sure that the feature is in all versions.

Although this works for this example, this is not what the 4BSD dump/restore
do, and in particular, it is not reliable.  Consider, e.g., the following:

	0. file system backup done on 12/13/1989
	1. inode 12345 removed
	2. inode 12345 allocated by `tar' from archive made 12/1/1989:
	   timestamps are atime=12/1/1989, mtime=12/1/1989, ctime=12/14/1989

Now we run the backup program.  If it saves only the inode contents, and
not the file contents as well, it will assume that (since inode 12345
was on the dump made on 12/13, and its mtime is 12/1) the contents are
good and it needs only the permissions, times, etc.  If we subsequently
restore the file, we will find that it has the permissions of the file
created by tar, but the contents of the file that was removed in step 1
above.

>It is important to understand the distinction, however, between changing
>the contents and the characteristics. The field which indicates that the
>file content has been changed is the modified time (find param -mtime).

Almost, but not quite, because of utimes(2).  The mtime can, at any time,
be changed to either `now' or any arbitrary value.  If you examine the
kernel source, you will see that whenever the mtime is changed, the ctime
is also changed to `now'.  In other words, modifying the file's contents
updates the file's ctime.

(dump is a bit paranoid, checking both the mtime and ctime when doing
backups.  This is unnecessary, and in fact will back up too many files
if utimes() is used to set the mtime into the future.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris