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/bucket-file-upload/2copy.mp3': 'OK', 'Known viruses': '8931107', 'Engine version': '0.102.4', 'Scanned directories': '0', 'Scanned files': '1', 'Infected files': '0', 'Data scanned': '0.00 MB', 'Data read': '5.04 MB (ratio 0.00:1)', 'Time': '22.727 sec (0 m 22 s)'} I am using "clamscan" inside a Lambda function to scan the file which is uploaded to an AWS S3 bucket. regards Ankur On Wed, Nov 4, 2020 at 4:51 AM 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 > > > > _______________________________________________ > > 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 > -- regards Ankur +61481141085
_______________________________________________ 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