RobertTurner

And that's exactly what I'm using the CLS for -- scanning a file on a local disk. There is nothing about the license that says I cannot scan files on my disk at will with the command line scanner. This is a server product for a *nix platform. This is exactly the sort of thing many system admins would want to do. I just want to integrate the scanner I already have into a product I already have (as I have with so many other scanning products in the past). Why have a command line scanner if you cannot scan files with it?! I don't want to be developing custom products and developing solutions for others and deploying them. The API is not where I want to go, nor does it make logical sense for what we are doing. Maybe it's all you have to offer, that's why this is a "feature request". It sounds more like ESET is not the right product for *nix server solutions and I would be better off with other solutions like clamav (which seem to understand the *nix solution space better - they aren't good for "end-users" though).

I should also add that I have not observed this overhead on the Windows File Security command line scanner, only on the Linux and OSX versions.

I think maybe you mean "not intended" instead of "proper". However, I don't see much other purpose for the command line scanner if it isn't to scan files and get the results. What would the command line scanner be for if not that? Wanting it to be efficient and work with the already loaded scanning system is hardly anything special -- things like this have been around for decades. This is a "server product" right? It should support automation and integration into local tooling... Can you point me to the ESET API documentation? Contacting a distributor is not normally how ones get information about APIs, nor an approach that I would deem useful. It would likely take weeks to get any form of answer. The only documentation I can find is related to the Server_API for interacting with the management center, which is not at all useful for what we want. Is there some other API hidden away? Also, using an API is highly non-flexible or generic for integration into other tooling. Basically we would end up writing a command line scanner tool to scan the file via the API -- which sounds an awful lot like what's already there...

When using the Command Line Scanner (cls) to scan individual files while being uploaded to a server (we need to invoke the scanner for each file so we can reject an upload and abort an associated DB transaction), cls takes a few second to load all it's data/dictionaries/etc. It would be better if cls supported streaming the file via the already loaded scanning daemon, or could spawn a shared scanning daemon, so as to avoid reloading all the data each time. The lack of this functionality adds significant overhead when processing a lot of files (which our systems do daily). clamav supports this functionality using "clamdscan" instead of "clamscan. It would be good if ESET could support this as well.