brebell
commented
2 months ago The --max-files option does not limit the number of file scans that clamscan will perform. It limits a single scan to stop scanning after X-number of embedded files are found. For example, using clamscan --max-files=8 will terminate a scan early for a zip containing 9 files.
Please use the -- help output for clamscan states: --max-files=#n The maximum number of files to scan for each container file (**)
You can adjust to your preference.
MiscMyth
Greetings, Clams! Not sure if that's how I should address this community as it is my first time posting. But long story short, the --max-files option does not appear to be considered by clamscan. Below I'll attach some screenshots to visualize the issue.
As visible in the photo above, I have set the maximum files to scan in the directory to eight (8), but if you count the total files scanned it's apparent that though it's scanning exclusively one directory with no sub directories and no references to files within the test document. (They all just say 'Test' inside). But this clamscan test runs across the entire directory and fails to cap the files searched at eight. I am aware this is a very low number, but I do not believe that should affect the issue. This issue happens in all programming languages and in the command prompt as seen. The issue does occur in any directory with or without recursive set.
For the record, here's the description of what --max-files is supposed to do as according to --help:
--max-files=#n The maximum number of files to scan for each container file (**)Again, I'm using win64x
If you'd like a photo of the directory being scanned, here you are:
Though note that this doesn't appear to have any relevance as though it has this issue regardless as to the scanned directory or sub-directory. For all of the mentioned reasons, I believe I have reason to assume this as a bug. I could not find any specific posts here on this subject nor could I find a solution or workaround anywhere.
Cheers, :) Misc. Myth