On Fri, 2006-01-13 at 17:21 -0600, Les Mikesell wrote:
> On Fri, 2006-01-13 at 16:44, Johnny Hughes wrote:
> > On Fri, 2006-01-13 at 15:24 -0500, Bowie Bailey wrote:
> > > rado wrote:
> > > > On Fri, 2006-01-13 at 13:02 -0500, Bowie Bailey wrote:
> > > > > rado wrote:
> > > > > > hi!
> > > > > > 3 machines all run this same test script. 2 -i386, 1 x-64bit
> > > > > > machine.
> > > > > >
> > > > > > this line:
> > > > > >
> > > > > > if find / -mount -type f -mtime -1 -print0 | xargs -0 clamscan -l
> > > > > > \ $CLAMDAILY $CLAMEXCLUDES -r --no-summary | cut -d: -f1 >
> > > > > > $CHANGEDLOG; \ then
> > > > > >
> > > > > > the $CHANGEDLOG file... on the 32 bit boxes...oh, probably 220
> > > > > > files. On the 64bit box 177,999 files lol (Centos 64bit
> > > > > > w/everything installed)!
> > > > > >
> > > > > > it seems to me that the system is disregarding "-mtime -1"
> > > > > >
> > > > > > sure has me puzzled! I have rechecked all of my assigned variables
> > > > > > over and over in the cfg file and the syntax of the functions in
> > > > > > the functions file that make up the whole "team". I can find
> > > > > > nothing remarkable relating to the 64 box's cfg.
> > > > > >
> > > > > > any suggestions?
> > > > >
> > > > > It seems to work fine on my 64-bit machines.
> > > > >
> > > > > Try running this to see what is being selected:
> > > > > find / -mount -type f -mtime -1 -print0 | xargs -0 ls -ld >
> > > > > new_files.txt
> > > > >
> > > > > With the 'ls -ld', you will see the modification times as well, so
> > > > > you can tell if it is really selecting the wrong files.
> > > > >
> > > > yes, it really is selecting the wrong files...getting all kinds of
> > > > dates...
> > >
> > > Time for the mantra of computer techs around the world:
> > >
> > > "Hmm...that's odd...it shouldn't do that..."
> > >
> > > Don't know what else to tell you. Anyone else have any ideas?
> > >
> >
> > How is the file system mounted in /etc/fstab
> >
> > (any weird options)
> >
> > What is the file system?
>
> 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?
