Re: On-Demand Anti-Virus Checking Software
From: Hector Santos (nospam@nospam.com)
Date: 01/26/03
- Next message: Stegie: "Re: VM problem!! What ever that is!!"
- Previous message: Bill Sanderson: "Re: VM problem!! What ever that is!!"
- In reply to: x y: "Re: On-Demand Anti-Virus Checking Software"
- Next in thread: x y: "Re: On-Demand Anti-Virus Checking Software"
- Reply: x y: "Re: On-Demand Anti-Virus Checking Software"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Hector Santos" <nospam@nospam.com> Date: Sat, 25 Jan 2003 20:31:28 -0500
> > Can you explain this better?
>
> What I mean is that most of these protocols, such as email, FTP, web
> browsing, etc. generally don't infect you with a virus until a file is
first
> written to your hard drive. So, my on-access scanner would catch it.
Well, until the code is actually executed... right? Storage means nothing.
I guess what I really was trying to understand is what does "on-access"
mean?
You mean "on-the-fly" or direct harddrive storage scanning?
> For this reason, I felt that attempts by McAfee and other vendors to sell
and
> run FTP and HTTP virus scanners for the desktop in addition to the regular
> on-access scanner were marketing mumbo-jumbo or poor planning. It seemed
to
> me that all these extra scanners being loaded in memory caused more error
> messages and consumption of system resources.
Ok, I think I understand your point.
If by On-Access you mean the direct harddrive I/O scanners, if the
on-access engine is already loaded, then there has do be logic that another
application can control it.
In the early days of when they came out, they really put a major strain for
many our high-end mail/file customers to the point, we often had to
recommend shutting them off or if the software allowed it, isolate the
folders to be automatically scanned. But they have improve over the years
and we don't hear much about the strain problem.
> [By comparison, the NAV on-demand scanner has a plugin that will interface
> with Outlook email to send an email back to the sender that they are
> infected... something that the on-demand scanner can't do alone. So this
> plugin does add value... but AFAIK it's done without having to run a
> separate scanner .EXE process in memory.
Yes, I see. You have a good point. If the vendor only offers a command line
applet, for a multi-threaded system like ours, it could be running multiple
instances of the applet. That is every overhead.
>From our end, a server software, not a desktop, it has to be a on-demand
concept in order to work efficiently and preferrably, support multi-threaded
on-demand scanning. Whether its done via a new process or via API
interfacing, that will depend on the vendor. I just need to be able to do
it it on-demand. The "on-access" or desktop editions with direct file I/O
scanners do not work for a complex client/server system such as ours. I
guess it could if it offers a "File Queuing" concept. Ideally, an API call
as follows would be something that would work great:
result = vendorScanFile(FileToScan, GoodStoragePath, BadStoragePath)
This will make it work better with a background file scanner engine. I
believe, as I read it, the grisoft AVG engine offers something along these
lines with their API.
Thanks
-- Hector Santos Wildcat! Interactive Net Server http://www.santronics.com
- Next message: Stegie: "Re: VM problem!! What ever that is!!"
- Previous message: Bill Sanderson: "Re: VM problem!! What ever that is!!"
- In reply to: x y: "Re: On-Demand Anti-Virus Checking Software"
- Next in thread: x y: "Re: On-Demand Anti-Virus Checking Software"
- Reply: x y: "Re: On-Demand Anti-Virus Checking Software"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|