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.