I´ve been reading "VSE 8.8 - What's New.pdf" and thinking about the new behaviour with persistent caching feature. Basically, VSE won´t scan a file that has been cached as clean, ok so far.
My question: Does this behaviour only happen when accessing the file for reading but still scanning the file when writing? Otherwise I think it might be a "problem" cos it won´t scan a cached file again that it might have been infected.
And when the cached list is regenerated or deleted? In VSE 8.7 it was when evey new session.
Hi dnf, I think an item won't be analyzed again unless it has been changed. When a file has been infected then its hash changes and VirusScan detects it so it analyzes it again
Yes, the cache is flushed and files re-scanned upon DAT version changes.
However, this applies to On-Demand Scanner and has nothing to do with On-Access scans.
From the Best Practices Guide, page 32, Configuring the scan cache:
[quote]Configuring the scan cache
The VirusScan Enterprise scan cache saves a list of scanned files that are clean. This improves
your system performance by saving this clean file scan cache information during a system
reboot. This also allows the on-demand scanner to use this clean file cache information to
reduce duplicate file scanning.
These options should remain enabled for the best boot time and overall system responsiveness
during on-demand scans.
NOTE: Disable these settings during a malware outbreak or if your security requirements are
Page 33: [quote]Configuring the scan cache
To configure the scan cache settings using the ePolicy Orchestrator, access the VirusScan
Enterprise 8.8.0, General Options Policies, and click the Global Scan Settings tab.
Enable the following scan cache settings:
• Enable saving scan data across reboots
• Allow On-Demand Scans to utilize the scan cache
The following ePolicy Orchestrator 4.5 shows the scan cache enabled.
The caching applies to On-Demand Scans, not to On-Access reads and writes.
Hopefully this clarifies expectations of Scan Caching
Message was edited by: rmetzger (redact incorrect info) on 8/2/13 11:41:29 AM EDT
on 8/2/13 11:46:01 AM EDT
I need to correct some comments and add clarity here -