Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.unix.questions
Subject: Re: find
Keywords: time atime mtime ctime
Message-ID: <1989Dec13.233435.9605@chinet.chi.il.us>
Date: 13 Dec 89 23:34:35 GMT
References: <21721@adm.BRL.MIL> <1989Dec12.060748.29698@csusac.csus.edu> <21231@mimsy.umd.edu> <1917@crdos1.crd.ge.COM>
Reply-To: les@chinet.chi.il.us (Leslie Mikesell)
Organization: Chinet - Chicago Public Access UNIX
Lines: 32

In article <1917@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) writes:

>  No. ctime is the time of a change to the *inode* not the file. 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.

If the ctime has changed, you don't have any way to tell how much
else has changed, and thus the proper thing to do is to copy the
current state.
For example:
 files foo.1 and foo.2 exist
 make your full backup
 mv foo.2 foo.1
 make your incremental based on mtime + the inode info
If you restore this, foo.1 is not going to contain what it did at
the time the incremental was taken.  Likewise if you copy files in
with cpio -m or anything else that can maintain the mtime.
 
>  The only backup which appears to take advantage of this is "dump," and
>I'm not sure that the feature is in all versions. 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).

Perhaps if the incremental is based on inodes instead of directories
it would notice these changes, but "find -mtime" won't.

Les Mikesell
 les@chinet.chi.il.us