Was running the old Command Line scanner but recently switched over to the new 6.0.0 scan engine because support of the old DAT files was being dropped. Previously, every scan ran fine with no "not scanned" files. Out of 120,000+ files, all were scanned. Now, with the new engine and AVV DAT files, over 30,000 files are not being scanned. For example, in the /usr/sbin directory there are 448 files. On the old CL scanner, all were scanned. Now, only 45 are being scanned. If I run the scanner manually and only check that directory, all will be scanned - just like when I ran the automated script with the old engine. Using the same task files however, most of the files are now skipped. The tasks are simple: move, summary, recursive, clean, maxfile size 5, and an exclude file to skip swap file systems. I've read and re-read the install guide, but the options all appear to be identical with the old engine. Why aren't so many of the files being scanned?
x86 system HP server, running Solaris 10. Scan engine 126.96.36.1999, latest AVV DAT files uploaded yesterday (5888).
Update: According to both guides (old and new), the --maxfilesize is listed in MB. --maxfilesize 5 means scan anything less than 5 MB. However, with the new engine, --maxfilesize 5 is cutting out anything below approximately 5k. I upped the maxfilesize to 50 and only 100 files out of 448 were skipped. Upped to 500 and only four files were skipped. However, out of those four files, only two were actually larger than 500K. Something is not right with this option now, whereas it was working fine before with the old engine. Is this a bug?Message was edited by: mdinaz on 2/12/10 10:37:06 AM CST
The scan options are pretty much the same as far as i'm aware. (There's a few new ones for example)
If you run a manual scan which is functioning as expected then i'm afraid the issue is likely somewhere in the automation script you're using.
Debugging a home-grown automation script is not something you can log a support call for with McAfee unfortunately but perhaps colleagues here will be able to make a peer review if you can post it.
Perhaps there's also some clues or a pattern from the 45 files being scanned vs the remainder which are not being scanned in /usr/sbin ?
Are the files being scanned all in the root of that path for example ?
If you have the summary output and are willing to share it maybe that'll help us identify a cause.
The problem appears to be definitely related to the --maxfilesize option.
For instance, if I run ./uvscan --verbose --summary /usr/sbin, it scans all 448 files. The largest file is 1.4M, the next largest is 576K, then 478K, 350K, and then the bulk of the files are 85K or less.
If I run ./uvscan --verbose --summary --maxfilesize 5 /usr/sbin, then it should scan all the files because the --maxfilesize n is listed in MB, according to the docs. This is what worked just fine in the past with the old scan engine using V1 dat files.
However, ./uvscan --verbose --summary --maxfilesize 5 /usr/sbin yields only 42 files scanned with the new scan engine and V2 dat files. If I do a find /usr/sbin -size -5000c -type f, the result yields 40 files. Add in links and and the total goes up to around 120.
Only by running ./uvscan --verbose --summary --maxfilesize 1400 /usr/sbin, do all the files get scanned whereas before --maxfilesize 5 was sufficient. What changed? I am running the same CL version (188.8.131.529) and same AV Engine (5400.1158) on a Linux Red Hat system and am having the same problem there as well as on Solaris 10.
The doc supplied with version 6.0.0 says: "Examine only those files smaller than the specified size. Specify the file size in megabytes. For example, maxfilesize 5 means scan only files that are smaller than 5MB." This is identical to the old docs.
Hm, that seems to warrant further investigation, thank you for narrowing it down.
I'd suggest you please open a support case so we can look at it in more detail.
Make sure to quote this forum discussion at the time to speed up the process.
At the least I suspect we'll need scan output from uvscan and a matching directory listing showing file size showing the discrepancy.
Whatever mer script that support will request from you will likely not include this information.
I'll ping our developers off-line about this anyway in the mean time to see what they think.
First impressions are it's treating the value as KB, not MB as stated in the product guide.
I would expect it to function as before (as stated in the guide), so please log a support call if you can so it can be invesitgated further.
I will try to get a call opened if possible. These systems are owned by the US Army and I need to find out what the Grant number is so that I an open a call. Thanks for the assistance.
Update: It will take a few days to get a call opened. The ACERT team will not release the Grant number so I have to get on a conference call with support to get a call opened. I will post the call ID once that occurs. Thanks.Message was edited by: mdinaz on 2/17/10 12:23:17 PM CST
Thanks for the case number.
I'll find the case, and put a note in it that is should be escalated to Engineering.
...And the interactive mode is broken as well...
./uvscan -f -
USED to allow interactive submittal of files, as is standard in UNIX, but not simply reports "can't open file"
I've heard that support for the entire command line interface is being eliminated 1/2011...
Anybody know of a replacement product?
Where did you hear that? So far on McAfee's EOL page, the only thing indicated is that support for the V1 dat files ended this month. No mention of the entire product being phased out.