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?