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. Rounding 68 bytes to 0.02 MB also would suggest a bug of some sort. Perhaps it would be best to be explicit and simply report 16 kb blocks read and scanned, rather than megabytes read and scanned. Maybe there is a better word than "blocks" (which suggests disk blocks), such as "segments", "sequences", "pieces"? On Wed, 4 Nov 2020 17:49:09 +0000 "Micah Snyder (micasnyd)" <micas...@cisco.com> 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-boun...@lists.clamav.net on behalf of > clamav-users@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@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
