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@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" <grschm...@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@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
