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 ?
Dump looks at both the mtime and the ctime when deciding to copy a file during an incremental dump. If either have changed then the file needs to be dumped.
The following change the ctime, but do not change any file data, and hence do not change the mtime:
rename file change owner/group of file change permissions of file
Some folks are unhappy when a virus scanner trips all the atimes (last read access) on all files. You lose valuable info about which files have not been read in a long time, because the scanner reads them often. So some virus scanners save the atime and put it back. But this trips the ctime, which causes all files to be copied by an incremental dump.
If you can configure your scanner to not preserve the atime, that would will fix it, but all your atimes will be tripped by the scanner.
I belive that netapp's NDMP dump has a flag or option where you can tell it to ignore ctime and only use mtime when doing an incremental dump. The downside is that an incremental dump will skip files that you probably want dumped. In addition to the cases listed above, if you un-tar or unzip an archive, the resulting files will have their old mtimes preserved, which may cause an incremental dump to skip them. This is not a problem when dump uses mtime and ctime, because the ctime is tripped when tar or unzip restores a file.
Steve Losen scl@virginia.edu phone: 804-924-0640
University of Virginia ITC Unix Support