Here is the problem with virus scanners and the netapp.
1) virus scanners must read a file to check it for viruses.
2) This trips the atime on the file. The filer does this whether you like it or not. You can configure a filer to NEVER trip atimes with: vol options volname no_atime_update=on But if atimes matter to you, then why would you do this?
3) Some folks object to having the atimes of all files tripped by a virus scanner.
4) To solve 3, some virus scanners save the atime before reading a file and put it back when they are done.
5) On a netapp, when you do 4, it trips the ctime.
6) Under normal circumstances, an incremental dump copies all files whose mtime or ctime has changed.
7) Because of 4, 5, and 6, incremental dumps become full dumps, essentially.
8) Netapp's NDMP dump has an option to ignore ctime. I don't think this is a good idea because this causes dump to skip files that really should be dumped. If you rename a file, change its owner/group, or change its permissions, you probably want that change reflected in a dump. But these operations only trip ctime, not mtime. Also, if you read files from a tar or zip archive, the old mtimes are preserved, so dump may skip these files.
The simplest solution is probably to run the AV scanner on a snapshot, which is strictly read only, so it's impossible for the scanner to change any file timestamps. The scanner may require some configuration to run in a read-only environment.
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 ?
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support