We use Norton AntiVirus 5.0 to scan our filers every evening. Norton has no
way to exclude the ~snapshot from bescanned, so they're scanned every
evening without incident. Of course, it fails when it tries to repair, but
that is not a problem.
> -----Original Message-----
> From: Stephen Manley [mailto:stephen@netapp.com]
> Sent: Friday, June 09, 2000 5:38 PM
> To: scl(a)sasha.acc.virginia.edu
> Cc: stephen(a)netapp.com; toasters(a)mathworks.com
> Subject: Re: NDMP Incremental backup issue
>
>
> > >
> > > The history of this bug:
> > >
> > > Some customers were encountering problems with various Windows
> applications
> > > using the Win32 API.
> > >
> > > Apparently, the ctime of an accessed file is updated by a large
> number
> > > of Windows apps (even if the file is only read) because the apps
> > > don't understand "last changed time".
> > >
> > > Thus, users with virus scanners would find that their incremental
> dumps
> > > included all files in the system...
> >
> > This sounds like a similar problem with the unix "file" command on
> some
> > systems. The "file" command tells you what type of file you have.
> > Usually "file" has to read the first few bytes of the file to figure
> it
> > out. This, of course, trips the atime. But then "file" tries to
> cover
> > its tracks by setting the atime back to its original value.
> > Unfortunately, this trips the ctime, which also causes a needless
> > incremental dump of the file. So are you saying that virus scanners
> also
> > save the atime and set it back? Makes sense because otherwise the
> atime
> > of all the files on the system are reset whenever a virus scan is run.
>
> > But resetting the atime trips the ctime, causing all files to be
> included
> > in an incremental dump.
> >
> > But there are important reasons to dump files whose ctimes have
> changed,
> > so ignoring ctime isn't the answer.
>
> Agreed.
> That's why the workaround of "ignore_ctime" is not a standard
> documented option, and should not be used by most NetApp customers.
>
> Those who have used it understand the ramifications of their
> decision.
>
> Longer-term solutions to the problem are mentioned in the
> bug description for burt 17767. One possibility is to allow
> CIFS users to choose to use the "Archive bit" semantic.
>
> The archive bit is the Windows way of not worrying about any
> of the mtime/ctime business. I believe it is cleared when
> the file is backed up, and set when the file is modified...
>
> Priority 1 was to fix burt 23356, so that those of you
> who aren't worried about burt 17767 are not affected by it.
>
> We are working on the "right" answer for 17767.
>
> Stephen Manley
> NDMP Time Keeper
>
>
>
> P.S.
> > A possible workaround would be to have the virus scanner check a
> snapshot.
> > Then the virus scanner can't change any timestamps at all since the
> > snapshot is strictly read only. Of course, the virus scanner might
> croak
> > when its attempt to reset atimes in a snapshot fails.
>
> BTW -- this was a suggested approach for the virus scanners. I don't
> have data on the success rate of this choice.
>