Hey Paul.
We use NAI (McAfee) for Linux here and I wrote a little script that directs the scanner what to scan (ie, to avoid snapshots etc). It has a handy dandy switch to preserve atimes. I'd suspect NAV has something similar. In fact, I just poked around their support site (I'm considering switching AV providers) and they have this to say in the release notes for Norton AV Corporate 7.03:
Issue: Manual and Scheduled Scans would alter the "Last Modified" timestamp on some types of files (most commonly, text files). In some specific cases, this caused problems with certain file archiving, backup, and compare tools. Resolution: Scans no longer change this date.
Is that not the case? I'd be very surprised if they don't have some way around this. While I appreciate the thoughts of the other folks that say "just ignore atime", it seems there should be (and in fact there is for McAfee customers) another and better way around this - just don't touch it to begin with. Is there some other reason that ignoring atimes is important that I'm just not getting??
-Dustin
On Tue, Jan 30, 2001 at 02:58:40PM -0500, Paul Letta wrote:
We are using Norton AV Enterprise 7.01 to scan our filer via CIFS. We have found that as Norton scans each file, the inode change time (i.e. ls -lc) gets set to the current time. I think it is due to Norton messing with the DOS archive bit, but I am not sure.
The problem is that this turns our level 1 ndmp dumps into virtual level 0 dumps. It seems that ndmp uses the inode change time, not the file modification time, as a basis for picking which files to dump during level 1's.
Any suggestions ?