I'm happy to report we located the bug which was not at all due to clamav. However knowledge gained! Thanks everyone.
On Fri, Aug 28, 2015, 12:31 Shawn Webb <latt...@gmail.com> wrote: > On Thursday, 27 August 2015 01:48:00 PM Charles Swiger wrote: > > On Aug 27, 2015, at 1:13 PM, Alexander Urcioli <alex...@gmail.com> > wrote: > > > We were running into an issue where larger files were not able to be > moved > > > after scanning with ClamAV. Our hypothesis was that perhaps the process > > > has > > > not released access to the file and we were experiencing a race > condition. > > > > > > Upon investigating I attempted to monitor the file we were scanning > using > > > lsof on repeat mode. To my suprise, upon scanning a 900MB file with > > > clamscan and clamdscan, lsof never lists the file as being opened > > > by....anything... > > > > It's not unusual for programs to read file data via mmap() rather than > > open(). > > > > That said, it's also quite possible that a 900 MB file is being skipped > > entirely due to MaxScanSize setting, which defaults to 100 MB unless you > > have changed it. > > A file descriptor still has to be opened for mmap. lsof would show that > file as > being opened. Your thinking about ClamAV's scan size settings are likely > correct. What I'd do is scan that one archive with verbose debugging mode > enabled in clamscan. That will tell you if ClamAV skipped the file due to > scan > size limits. > > Thanks, > > Shawn_______________________________________________ > Help us build a comprehensive ClamAV guide: > https://github.com/vrtadmin/clamav-faq > > http://www.clamav.net/contact.html#ml _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
