[clamav-users] ClamAV Scan - Data Read vs Data Scanned

[Mark Fortescue]

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" <clamav-users-bounces at lists.clamav.net on behalf of clamav-users at lists.clamav.net> 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 MiB) for
>      tiny files. By normal rounding rules this should display as 0.02 MB/MiB.
> 
> 
>      On Tue, 3 Nov 2020 17:50:18 +0000
>      Mark Fortescue via clamav-users <clamav-users at lists.clamav.net> wrote:
> 
>      > 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 just round up by adding (BlockSize - 1) bytes when setting
>      > the block variables ?
>      >
>      > Regards
>      > 	Mark.
>      >
>      > On 03/11/2020 16:07, Paul Kosinski via clamav-users wrote:
>      > > "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 +1100
>      > > "Gary R. Schmidt" <grschmidt at acm.org> wrote:
>      > >
>      > >> 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
>      > >> architecture, only a step or tow above assembler, or doing the
>      > >> bit-twiddling by hand.
>      > >>
>      > >>> When I wrote code in the mid 1990s for the DEC Alpha, ints were 32 bits
>      > >>> while longs were 64 (unlike "standard" C). This made Alpha C code not
>      > >>> portable to lesser CPUs. On the other hand, when I wrote C on DOS for
>      > >>> the IBM PC in the late 1980s, ints were only 8 bits! It took some time
>      > >>> to figure out why my C-compliant code failed so badly. In spite of all
>      > >>> that, having started programming before C was invented, I can safely
>      > >>> say that C is better than its predecessors for software like ClamAV.
>      > >>>
>      > >> Uh, not a good example, I've written C code that is still in use on
>      > >> everything from 80286s (yes, Virginia, there are people who keep them
>      > >> alive, not just because they're cheap, sometimes just because they
>      > >> *can*) to DEC Alphas and Power and SPARC64 and PA-RISC, it's just a
>      > >> matter of knowing what you are doing, and sticking to it...
>      > >>
>      > >>> P.S. Good code these days tends to use typedefs defining things like
>      > >>> int32, uint64 etc. A shame the original ClamAV coders didn't do that.
>      > >>>
>      > >> And none of this has *anything* to do with the original problem - seeing
>      > >> 0 when the value is 0.0000000001, or so.
>      > >>
>      > >> This is a display problem, not a storage problem.  You could declare
>      > >> something as PIC(9999999.99999999999999) and you will still only see 0
>      > >> if you told it to display two decimal places.
>      > >>
>      > >> 	Cheers,
>      > >> 		Gary	B-)
>      >
> 
>      _______________________________________________
> 
>      clamav-users mailing list
>      clamav-users at lists.clamav.net
>      https://lists.clamav.net/mailman/listinfo/clamav-users
> 
> 
>      Help us build a comprehensive ClamAV guide:
>      https://github.com/vrtadmin/clamav-faq
> 
>      http://www.clamav.net/contact.html#ml
> 
> 
> _______________________________________________
> 
> clamav-users mailing list
> clamav-users at lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
> 
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml
>