We're having similar problems to https://community.mcafee.com/thread/61373?tstart=0 and https://community.mcafee.com/thread/61643?tstart=0 .
FoxPro has a command called PACK, which permanently removes all records marked for deletion in a database table. FoxPro stores data in .DBF files. Internally to FoxPro, The PACK command copies the records not marked for deletion from the .DBF file to a .TMP file in the temporary files folder. It then deletes the .DBF file and then renames the .TMP file in the temp folder to the .DBF. This all happens with the single PACK command.
The error we're getting is "File Access Denied". The real problem though is the .DBF file is gone, and the .TMP remains in the temp folder. The data then is basically lost. Not good at all. This does not happen all the time, but often enough.
We're also seeing problems with other FoxPro commands, which we've attributed to McAfee's Real Time Protection.
Our software has been working properly for over 10 years with McAfee users, this problem just started maybe 3 months ago.
Is there a solution?
As was recommended in both of those threads, Technical Support are better equipped to deal with this sort of thing.
There is an Enterprise (Business) KB article here regarding obtaining clearance for commercial software makers: https://kc.mcafee.com/corporate/index?page=content&id=KB66642&pmv=print
We have this exact problem showing up in the last several months. Clients using McAfee Internet Security, specifically the real time scanner, are experiencing the "File Access Denied" when running our Foxpro application which has been in use in some form since late 1980s. I too believe it is during a Foxpro PACK operation, which requires an exclusive lock on the DBF in question. My guess is that it is something to do with the timing of the locked file and real time scan trying to scan it that causes the error. Of course then the .TMP file remains and the original .DBF is gone and the app is hosed.
Since there is no option to exclude entire directories or wildcards from the real time scanner (like *.DBF, *.CDX, *.FPT) my only option seems to be to set the option in real time scanner to scan "only files and documents". Of course turning off the real time scanner completely works, but is a more aggressive and less safe option.
We can't touch our compiled legacy code easily and it is deployed to 700+ clients. I really wish McAfee would come up with a fix or workaround so this problem could be eliminated as I've seen references to it online for years.
Let me make it clear that this is NOT a virus issue with the file and no malicious code is suspected. It is simply the act of McAfee real time scan performing it's test on the file Foxpro is trying to pack that is causing this incompatibility and breakage.
If it's the home products doing this I suggest contacting Technical Support from a machine that is displaying the issue. It's free of charge by phone or online chat and linked under Useful Links at the top of this page.
If Enterprise products, then contact through that support portal.
We've been working with the "McAfee Tier 2.5 Team" for the past couple of months. A couple of weeks ago they said the problem is fixed, but not how users get the fix. We are still seeing the problem and emails to the support team about how to get the fix have gone unanswered.
Email is by far the slowest method of obtaining support. Try phoning or use online chat as I suggested and quote the most recent case ID#.