Re: [Clamav-devel] PATCH: Enhanced exclude / include support…

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Mark Allan
Date:  
To: ClamAV Development
Subject: Re: [Clamav-devel] PATCH: Enhanced exclude / include support forclamscan
>> The regular expressions being excluded or included are compiled
>> just once and stored in memory



Brilliant!

> On the one hand, you're right that were clamscan to have a command-
> line option to tell it to read a list of files on stdin, the logic I
> built into it could be implemented externally, either with home-
> grown scripts or with a separate utility bundled with clamav. I
> certainly wouldn't be adverse to achieving my goal that way, where
> that functionality to be provided by clamscan.


I think this way would be much better than changing the interface, and
would have the added benefit of being significantly more powerful than
you probably realise. If we could supply a list of files either on
stdin or within a single text file passed on the command line with eg.
a -f flag, users and admins could incorporate ClamAV into scripts/
tasks and automated jobs a lot more easily than is currently
possible. It would also eliminate another issue I've had to work
around which is the lack of case-insensitive regex matching - I could
perform my own matching and just supply filenames within a temporary
file or via stdin.

> Other applications in the same genre with similar functionality
> include rsync, rdiff-backup, and GNU tar. All of those, like
> clamscan, could force the user to implement exclude / include
> functionality externally and then feed a file list into the
> application, and yet all of them provide complex, flexible built-in
> filtering functionality of their own.


Indeed. I don't think anyone's suggesting that the existing
functionality be removed.

> Perhaps what is needed is a compromise -- basic filtering of the
> sort I implemented, *plus* the "-f" flag (or the equivalent) for
> people who want to roll their own logic?


In my opinion, that would be an ideal solution.

> Interfaces change. Such is life. Remaining wedded to broken
> interfaces leads over time to difficult to maintain code with
> inferior functionality and performance. The changes should be
> visibly documented, and people who are using ClamAV should be smart
> enough to read the release notes when they upgrade.


The problem isn't with changing the interface, the problem is that
your solution doesn't actually change the interface, it changes the
implementation - you've just placed extra importance on the order of
the items, which wasn't there before. This could have the subtle
effect of still appearing to work, but no longer doing what the user
expected. Files which should be scanned may end up getting missed and
the user might not realise. If the interface actually changes, then
that's not such a big deal as it will simply and very obviously break
any existing procedures a user has set up, and they'll have no choice
but to change how they work.

Mark

_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net