On Fri, 2006-01-13 at 22:39, rado wrote:
> >
> > Are you sure the dates aren't in the future? Many programs
> > can set the mtime on files, including windows boxes writing
> > through samba shares and the date might be wrong. It might
> > be better to use ctime which should always be set by
> > the local machine. You might get a few unnecessary hits where
> > only the owner/attributes changed instead of the content
> > but it might be more accurate. If you are scanning changed
> > files for viruses, a virus would only have to do the
> > equivalent of 'touch -B 10000 file' to avoid being scanned
> > when you only observe the mtime. Ctime will be set at the
> > time the change was made.
> >
>
> kk...w/ctime, it cut it down dramatically to 3200 files vs 180,000
> w/mtime... I presently switched it back to mtime but I really do think
> it will still shoot off the chart.
>
> I sure don't mind using ctime instead but I just wish I knew what
> actually constitutes changes in files "status" .
>
> mtime...no question...a file's data is it's data. but ctime...file's
> status??? hummm permissions?
Ctime is the last inode change time. The owner, group, modes, link
counts and mtime are stored in the inode. If any of those change,
ctime is set to the time of the change. For example, you could
use 'touch' to set mtime in the future, but ctime would be
updated to the current time as a side effect. Since changing
the file content changes mtime, it also always updates ctime.
Ctime should always be used for things like incremental backups
so you get new files that have had mtime set back (like tar,
zip, etc. might) along with owner and mode changes.
--
Les Mikesell
lesmikesell@xxxxxxxxx
