How to configure on-access scanning to avoid unacceptable delays with trusted applications?

Update: I have verified that I'm using the correct syntax to specify exclusions from on-access scanning.  I have found additional directories used by my Java application, and added them to the exclusion list.  The first-time startup time of the application is still unacceptable.  Intercheck hogs the CPU when this happens, and not when the app starts up quickly, on subsequent startups.   It wasn't formerly like this, even though I was running SAV.  I think this problem is due to the most recent update of SAV.  I still don't know whether my understanding is correct, though.

Hello mars,

dunno about the recent versions (and my knowledge of the Mac version is limited). The engine (guess this is true for all platforms) keeps a list of files scanned to avoid rescanning until reboot (it might prune the list if it gets too large). I assume the exclusions work, the first-time (after reboot?) delay and scan activity suggest that other files are involved (perhaps Java "itself"). Do you have another Java application to compare the behaviour?

Christian

Thanks Christian.  It took a while before I had time to do testing.  Today I spent the better part of a hour rebooting, testing, revising exclusion lists, testing, etc.

At this point I've got these excluded, temporarily:

/usr/bin/java, which is a link to a file under the next directory listed:

/System/Library/Frameworks/JavaVM.Framework/

/usr/lib/

/usr/local/

and all directories containing files used by two different java applications: mine, and NetLogo 5.0.4.  All directories are listed with a final single backslash, so all files under them should be excluded as well, according to the Help file.

Adding the JavaVM.Framework directory made a big difference.  Now, the first time after reboot that I run either application takes about a minute or two, but then running the same application again, or running the other one for the first time takes only a few seconds.  Before that, each one was individually slow to load the first time, but fast the second time.

So it appears that there are still files that Java is loading that I don't know about.  It's not easy to figure out what they are.

I really shouldn't have to work this hard to get things to run in an acceptable way.

Why doesn't the on-access scan remember that a file has been checked after a reboot?  Most people are not going to access the a non-networked hard drive through some other means than using the current computer with the current OS with Sophos running, so a reasonable allowable configuration should be "don't check previously checked files ever again, unless they've changed".  Couldn't Sophos write a database of previously-checked files, with checksums?  I would think that running a checksum on a file would be pretty fast, compared to a complete scan for virus signatures--expecially for compressed files.

I also don't think it's a good idea to exclude subdirectories in which I don't explicitly control every file.  Adding /usr/lib and the JavaVM directories defeats the purpose of on-access scanning, unless one takes the view that all system directories are safe.  In that case, none of them should be scanned.  But that seems risky.  Keeping a permanent record of checked files with checksums would solve this problem.

Thanks!

Further info: Excluding /System/Library/Frameworks/Java* (i.e. other Java directories there as well) doesn't help.

No further help?? This is an intolerable situation.  I have a choice between turning off the live scan, waiting forever for software to load in some situations, or, possibly, downgrading to a previous version that didn't behave this way.  I get Sophos AV through a site license.  I'm ready to lobby my employer to look for a different product.  I'm not trying to be obnoxious about the situation, but I am very unhappy, as I think you can easily understand.  Sophos AV is not doing its job, in my opinion.  Please help.  Please tell me that you're working on it, at least.

Thanks very much for the clarification, Sandy.  These were things that I didn't understand.  It wasn't clear to me from the Sophos site that these forums were not intended as a substitute for tech support, and it wasn't clear that I have to contact my IT department given that I have a site license.

I will admit that this is a bit disappointing for me personally.  Our IT people very good with certain kinds of problems, and I have a lot of respect for them.  This problem, which I do see as the result of the most recent release of Sophos, feels to me to me like the kind of thing that's not the sort of thing they're good at addressing.  That's just a guess, and it's entirely possible that I'm wrong.  I'll contact them.

Thanks!