Sorry, forgot to CC the list (sometimes Reply All *is* appropriate).
I think it's important that ClamAV *not* say there were 0.00 MB
scanned/read, while also saying a file *was* scanned & infected.
Contradictions like this [might be interpreted to] suggest a serious
problem in the logic.
Hi there,
On Tue, 3 Nov 2020, Gary R. Schmidt wrote:
... I've written C code that is still in use on everything from
80286s to DEC Alphas and Power and SPARC64 and PA-RISC ...
Hehe, I wrote our invoicing, stock control and accounting suite in C
starting around 1986. Originally it ran under
Yes.
On 04/11/2020 17:49, Micah Snyder (micasnyd) via clamav-users wrote:
Do you reckon folks will be less confused if it rounds up?
-Micah
On 11/3/20, 1:37 PM, "clamav-users on behalf of Paul Kosinski via clamav-users"
wrote:
If ClamAV always rounded up when counting the number of
Do you reckon folks will be less confused if it rounds up?
-Micah
On 11/3/20, 1:37 PM, "clamav-users on behalf of Paul Kosinski via
clamav-users" wrote:
If ClamAV always rounded up when counting the number of 16kb blocks,
then it should be counting at least 0.016384 MB (or 0.015625
users ML
Date: Tuesday, November 3, 2020 at 12:41 PM
To: ClamAV users ML
Cc: Ankur Sharma
Subject: Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
Thanks a lot for all your inputs.
Further during the test I tried to scan a ".mp3" file of size 5.04MB. The
returned lo
If ClamAV always rounded up when counting the number of 16kb blocks,
then it should be counting at least 0.016384 MB (or 0.015625 MiB) for
tiny files. By normal rounding rules this should display as 0.02 MB/MiB.
On Tue, 3 Nov 2020 17:50:18 +
Mark Fortescue via clamav-users wrote:
> Hi all,
Thanks a lot for all your inputs.
Further during the test I tried to scan a ".mp3" file of size 5.04MB. The
returned log mentions the number of Scanned files as 1, but when I see the
Data Scanned - it is 0.00 MB. Does ClamAV support scanning MP3 files? Has
anyone tried scanning MP3 files?
Hi all,
I would call this a bug. Scanning 1 byte is the same as scanning 1 block.
When storing things in blocks is is always important to round up or you
get a false impression of reality.
You can't store 100 bytes in 0 disk sectors of 128 bytes. It is always 1
disk sector.
Can you not
"This is a display problem, not a storage problem."
I disagree. When the counts in info.blocks and info.rblocks are counts
of 16kb *blocks*, keeping precise track of the reading and scanning of
small files is impossible, no matter how clever the display code is.
On Tue, 3 Nov 2020 17:44:18
On 03/11/2020 16:00, Paul Kosinski via clamav-users wrote:
"(don't you love C?)"
I have never understood why the originators of C didn't give integers
explicit widths in bits: their scheme made C code often non-portable.
Because C is intended to be very, very close to the machine
users On Behalf Of
> > Paul Kosinski via clamav-users
> > Sent: Monday, November 2, 2020 5:23 PM
> > To: clamav-users@lists.clamav.net
> > Cc: Paul Kosinski
> > Subject: Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
> >
> > Can this really b
av-users@lists.clamav.net
> Cc: Paul Kosinski
> Subject: Re: [clamav-users] ClamAV Scan - Data Read vs Data Scanned
>
> Can this really be done? I was looking at the code referred to by G.W.
> Haywood, and I see that it uses "info.blocks" and "info.rblocks".
&
Can this really be done? I was looking at the code referred to by G.W.
Haywood, and I see that it uses "info.blocks" and "info.rblocks".
Looking at the definitions in "clamav-0.103.0/clamscan/", I see the
following:
struct s_info {
unsigned int sigs; /* number of signatures */
I agree. We already have some logic in freshclam to convert bytes to human
readable B / KiB / MiB / GiB format. It should be pretty much a copypaste
effort to improve the data scanned/read output.
-Micah
On 11/2/20, 9:47 AM, "clamav-users on behalf of G.W. Haywood via clamav-users"
Hi there,
On Mon, 2 Nov 2020, Paul Kosinski via clamav-users wrote:
... I still think it is a bad message that should be fixed.
+1
If you want to try a very quick and dirty tweak to get more precise
numbers, change the value of
1) CL_COUNT_PRECISION in .../libclamav/clamav.h from 4096 to 1
When I first saw this message, I quickly concluded it was a roundoff
behavior. But I still think it is a bad message that should be fixed.
First, most file managers that only display file sizes in "human
readable" form, still display a non-zero size for small files. Second,
it is not logically
The eicar test file is 68 bytes long which is .68 MB which rounded to two
significant digits is 0.00 MB both scanned and read.
There are various limits, depending on file and archive types as to how much is
read and/or scanned. In most cases they will be exactly the same.
-Al-
> On Nov 1,
Hi All,
I tried to scan an eicar test file and got the following scan output:
{'Scanning /tmp/bucket-file-upload/eicar_com.zip!ZIP': 'eicar.com',
'/tmp/bucket-file-upload/eicar_com.zip': 'Win.Test.EICAR_HDB-1 FOUND',
'/tmp/bucket-file-upload/eicar_com.zip!(1)ZIP': 'eicar.com:
18 matches
Mail list logo
