Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ClamAV: win32

How to handle wildcards with clamdscan?

 

 

ClamAV win32 RSS feed   Index | Next | Previous | View Threaded


dave at mvn

Feb 15, 2008, 8:54 AM

Post #1 of 7 (644 views)
Permalink
How to handle wildcards with clamdscan?

I didn't see this in the last few months of list archives; if it's a
FAQ, please yell at me. :)

I'm trying to get clamav-win32 to interface with my old creaky mail
server (Imail, with the Declude mail filtering add-on). Unfortunately,
this software is a bit dumb, and insists on giving me wildcards in its
command line.

When clamdscan gets called, it gets called like this:

C:\progra~1\clamav\clamdscan.exe -options c:\temp\foo\*.*

Thanks to its *nix heritage, clamdscan dutifully tries to open a file
named asterisk-dot-asterisk, which isn't there, everything fails, email
disappears, you get the idea.

(Internally, Declude appears to pre-process the email, separating out
any attachments and MIME-encoded bits, and puts everything in a
temporary directory, then asks your antivirus scanner of choice to scan
everything in that directory, hence the *.* . On Windows, that usually
works...)

Does anyone know of a wrapper program (or a ClamAV option) to work
around the fact that I'm being forced to deal with wildcards? I can
probably write a wrapper, but I'm not that familiar with Windows
development, and if someone else has already done it they've probably
done it better than I would.

David Smith
MVN.net
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32


bret.miller at wcg

Feb 15, 2008, 9:41 AM

Post #2 of 7 (621 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

If Declude can call a script (or cscript.exe), I'd tend to write a vbs
script and call it with the complete command line. It can parse the
parameters, remove the *.* from the end and pass just the folder name to
clamdscan, which should cause it to scan the folder, and then pass back the
return code. I suppose it would be more efficient to write it in C or
something, but there's really nothing complicated about stripping a bit off
the last parameter. I've got plenty of code, but none that does exactly
this...

Bret

-----Original Message-----
I didn't see this in the last few months of list archives; if it's a
FAQ, please yell at me. :)

I'm trying to get clamav-win32 to interface with my old creaky mail
server (Imail, with the Declude mail filtering add-on). Unfortunately,
this software is a bit dumb, and insists on giving me wildcards in its
command line.

When clamdscan gets called, it gets called like this:

C:\progra~1\clamav\clamdscan.exe -options c:\temp\foo\*.*

Thanks to its *nix heritage, clamdscan dutifully tries to open a file
named asterisk-dot-asterisk, which isn't there, everything fails, email
disappears, you get the idea.

(Internally, Declude appears to pre-process the email, separating out
any attachments and MIME-encoded bits, and puts everything in a
temporary directory, then asks your antivirus scanner of choice to scan
everything in that directory, hence the *.* . On Windows, that usually
works...)

Does anyone know of a wrapper program (or a ClamAV option) to work
around the fact that I'm being forced to deal with wildcards? I can
probably write a wrapper, but I'm not that familiar with Windows
development, and if someone else has already done it they've probably
done it better than I would.

David Smith
MVN.net


dave at mvn

Feb 15, 2008, 10:14 AM

Post #3 of 7 (623 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

Bret Miller wrote:
> If Declude can call a script (or cscript.exe), I'd tend to write a vbs
> script and call it with the complete command line. It can parse the
> parameters, remove the *.* from the end and pass just the folder name to
> clamdscan, which should cause it to scan the folder, and then pass back the
> return code. I suppose it would be more efficient to write it in C or
> something, but there's really nothing complicated about stripping a bit off
> the last parameter. I've got plenty of code, but none that does exactly
> this...

In my testing, stripping the *.* doesn't work either - clamdscan just
says it can't find c:\temp\foo\ and still errors out. What's probably
needed, then, is something that can expand the wildcards and pass the
results on to clamdscan.

Everything else can be hard-coded into a wrapper, for my purposes. I can
have Declude call "wrapper.exe", it'll expand that to "wrapper.exe
c:\temp\*.*", the wrapper will in turn expand that to "clamdscan.exe
-option1 -option2 c:\temp\file.1 c:\temp\file.2" and I can grab the
return code, pass it back up the chain, and in theory everything should
work. It's a bit of a hack but I'll take it.

David Smith
MVN.net
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32


bret.miller at wcg

Feb 15, 2008, 10:33 AM

Post #4 of 7 (621 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

What about c:\temp\foo (without the trailing slash)? That works for me...

Bret

-----Original Message-----

Bret Miller wrote:
> If Declude can call a script (or cscript.exe), I'd tend to write a vbs
> script and call it with the complete command line. It can parse the
> parameters, remove the *.* from the end and pass just the folder name to
> clamdscan, which should cause it to scan the folder, and then pass back
the
> return code. I suppose it would be more efficient to write it in C or
> something, but there's really nothing complicated about stripping a bit
off
> the last parameter. I've got plenty of code, but none that does exactly
> this...

In my testing, stripping the *.* doesn't work either - clamdscan just
says it can't find c:\temp\foo\ and still errors out. What's probably
needed, then, is something that can expand the wildcards and pass the
results on to clamdscan.

Everything else can be hard-coded into a wrapper, for my purposes. I can
have Declude call "wrapper.exe", it'll expand that to "wrapper.exe
c:\temp\*.*", the wrapper will in turn expand that to "clamdscan.exe
-option1 -option2 c:\temp\file.1 c:\temp\file.2" and I can grab the
return code, pass it back up the chain, and in theory everything should
work. It's a bit of a hack but I'll take it.

David Smith
MVN.net
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32


tmetro+clamwin32 at gmail

Feb 15, 2008, 11:40 AM

Post #5 of 7 (621 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

David E. Smith wrote:
> When clamdscan gets called, it gets called like this:
> C:\progra~1\clamav\clamdscan.exe -options c:\temp\foo\*.*
>
> Does anyone know of a wrapper program (or a ClamAV option) to work
> around the fact that I'm being forced to deal with wildcards?

You can pretty easily do that on a Windows NT-era system with a batch
file. Run "help call" at a command prompt to get documentation on the
ways in which you can modify parameters passed to a batch file. So for
example:

@echo off
C:\progra~1\clamav\clamdscan.exe %~p1


will take the first argument (%1) passed to the batch file and modify it
to return just the path, which is then passed as the first argument to
the real command.

clamdscan.exe should recursively scan the specified path.


If you really wanted to expand the wild card, that can be done too, with
additional effort. See "help for". It'd be something like:

FOR %file IN (%1) DO C:\progra~1\clamav\clamdscan.exe %%file

but far less efficient as it launches clamdscan.exe for each file.

-Tom

--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32


michael.m.minor at gmail

Feb 19, 2008, 7:13 AM

Post #6 of 7 (603 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

The "for" loop may be more efficient on systems with large memory and
multiple cores, to a point. Clamdscan will send the file to the running
instance of clamd anyway, wont it? Won't clamd handle the threading and
memory use and keep it manageable?

M^3

On Fri, Feb 15, 2008 at 2:40 PM, Tom Metro <tmetro+clamwin32[at]gmail.com>
wrote:

> David E. Smith wrote:
> > When clamdscan gets called, it gets called like this:
> > C:\progra~1\clamav\clamdscan.exe -options c:\temp\foo\*.*
> >
> > Does anyone know of a wrapper program (or a ClamAV option) to work
> > around the fact that I'm being forced to deal with wildcards?
>
> You can pretty easily do that on a Windows NT-era system with a batch
> file. Run "help call" at a command prompt to get documentation on the
> ways in which you can modify parameters passed to a batch file. So for
> example:
>
> @echo off
> C:\progra~1\clamav\clamdscan.exe %~p1
>
>
> will take the first argument (%1) passed to the batch file and modify it
> to return just the path, which is then passed as the first argument to
> the real command.
>
> clamdscan.exe should recursively scan the specified path.
>
>
> If you really wanted to expand the wild card, that can be done too, with
> additional effort. See "help for". It'd be something like:
>
> FOR %file IN (%1) DO C:\progra~1\clamav\clamdscan.exe %%file
>
> but far less efficient as it launches clamdscan.exe for each file.
>
> -Tom
>
> --
> Tom Metro
> Venture Logic, Newton, MA, USA
> "Enterprise solutions through open source."
> Professional Profile: http://tmetro.venturelogic.com/
> _______________________________________________
> http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32
>



--

Michael M. Minor
_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32


dave at mvn

Feb 20, 2008, 3:04 PM

Post #7 of 7 (592 views)
Permalink
Re: How to handle wildcards with clamdscan? [In reply to]

Michael Minor wrote:
> The "for" loop may be more efficient on systems with large memory and
> multiple cores, to a point. Clamdscan will send the file to the running
> instance of clamd anyway, wont it? Won't clamd handle the threading and
> memory use and keep it manageable?
>
I'm still trying to figure out whether it's more efficient to have a
very tiny .Net binary to do it, or a batch file, and to get either one
of 'em working right. I'll keep folks updated, because I find it hard to
believe I'm the first person ever to want to do exactly what I'm doing.

David Smith
MVN.net

_______________________________________________
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-win32

ClamAV win32 RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.