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?
{'/tmp/
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 jus
"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 +110
The gif I sent is part of teh signature of a mail
Nothing important
On 11/2/2020 11:04 PM, Micah Snyder (micasnyd) via clamav-users wrote:
Thanks Pablo,
Just took a look - it seems that image001.gif is missing the final byte, a value
"0x3B" should be at the end of every GIF file. Interestingly
Hi there,
On Tue, 3 Nov 2020, Micah Snyder (micasnyd) via clamav-users wrote:
Just took a look - it seems that image001.gif is missing the final
byte, a value "0x3B" should be at the end of every GIF file.
...
I wonder if this is a common occurrence. ...
It seems to be common enough to need
