Prevent EfaData\SYMEFA.DB from being created?

[Migration User]

Symantec Endpoint Protection 12.1.1000.157 RU1

WinXP Pro SP3

 

Whenever I mount a Truecrypt volume, SEP creates a \System Volume Information\EfaData folder and writes a SYMEFA.DB file to it.  This is extremely annoying behavior.

In order to get rid of this folder and its file, I have to add my username to its ACL, then unlock the two handles that are open on it, then I can delete it.... but every time I mount a volume, this gets recreated.

My university's tech guys had no idea what I was even talking about.

I tried searching your forums, but the only reference to EfaData I could find involved some kind of backup program.  I do not use any kind of automated backup software, and certainly not on encrypted data.  I also have System Restore disabled for all drives other than my system drive, so it has nothing to do with that either.

Interesting that SEP doesn't log any tampering entries when this folder is deleted.  What is it even used for?


tl;dr--
How can I prevent Symantec from writing these files?  I cannot mount the volumes as read-only because I need to work on the files in them.

[Migration User]

EFA is a new technology used in SEP 12 clients for file reputation lookups and EFA database is used to assist with the same. This behavior is by design and cannot be changed.

[Migration User]

This answer is not only unacceptable, but it is also false! For any non OS drive, you can format the drive usine exFat format instead of NTFS (from My Computer and right click n the drive). I did this on my new 1,5 GB Toshiba portable TO USB 3.0 drive and it removed this Symantec 'useless' file. I checked to see the size difference was between these two formatting methods, and they were equal. So, unless there is some kind of performance hit, this is the way to go in order to get rid of this useless and annoying file!. Symantec has no business writing non-removable files on your personal hard drives! To understand what exFat is, go to http://en.wikipedia.org/wiki/Exfat.

Vincent 06-24-13

[Migration User]

The original point remains valid. You should allow the user to opt out of the creation of these files on removable and/or external drives. Making the filesystem exFAT is certainly a workaround, but this isn't always convenient or even possible in some circumstances. Another dirty workaround is to create a System Volume Information folder on each and every encrypted volume I create (keep in mind, we're talking thousands) and setting the security permissions to deny access to that folder. If you absolutely feel the need to keep hashes for everything, why not store them on the OS drive Symantec is running on? Or at least give the user the option to do so? If you think about it, one of the main purposes of a security suite is to give the user complete control over who is allowed to do what, and prevent unwanted changes to the system. Symantec is making unwanted changes to my system, and I want it to stop. You provide us with so many settings in this software-- we can disable different features, fine tune the firewall with exact rules, and even create detailed exceptions to all the security features. Give us the means to opt out of this behavior.

[ℬrίαη]

As already stated, it's by design and cannot be changed.

You can post your concern in the Idea section so it can be reviewed for a future release.

[Migration User]

Cameron,

Once again, I must say it is useless to 95% of all users. This file does not exist on HDDs without Symantec software. I do not buy NIS (or the antivirus product) for any HDD 'benees'. This is a PC - PERSONAL computer  and I do not want anything on it I do not NEED. Making it unremoveable is inexcusable!!!!!! You are completely biased as to the need and benefit of this.

Since I last posted here about how to delete this folder and file (which you can do as I described in an earlier note) and the drive works just fine! I have been experiementing with ExFat (on Windows 7) and have discovered it does not use storage properly in that it wastes a lot of disk space, not matter how I formated the HDD. The best I could get is 101 GB (may hundreds of files) of real size gets stored as (space actually allocated) 119 GB. This is the best results, and with formatting at 128K per cluster, the minimum allowed. As you increase this, the 'waste' becomes an ever larger percentage. So, I am still looking for a way to remove this Symantec excess and not lose disk space!

After closer inspection, the reason that disk space is lost with ExFat is that the smallest size per sector is 128K (windows 7). On Windows 8 for a 64GB flash drive the minimun formatting cluster size is 4K, but I did not do any testing (formatting) on Windows 8. So, formating the HDD in NTFS at 64K per cluster ended up with essentially the same lose percentage (101.8 GB to 118.1), so this loss is not due to the ExFat format, but rather with the size per cluster selected when formatting. The default size per cluster when formatting in NTFS format is 4K (4096) on my 1.5TB external USB drive, and this results in a small lose of disk space also (101.8GB vs.102.2GB).

Furthermore, I have discovered that exFat format was originally designed for flash drives, and consequently, it is available for any USB attached drive as seen above in my example of the Toshiba 1.5 USB 3.0 drive. This format option (xFat)does not appear when trying to format internal HDDs. BUT, with an outboard drive docking station, you can attach 'internal' drives thru a USB port to the computer and format it in exFat format anyway! This means any drive can be exFat formated. In additon, the cluster size when formatting is determined by the HDD size. So, in my example above on Windows 8, a 64GB flash drive can go as low as 56K per cluster, so difference is probably not an OS version differentce, but rather simply the storage size difference - 1 TB at a minimum of 128K) vs. 64GB (at a minimum of 4K). See support.microsoft.com\kb\140365 for a complete discussion on all formats for all Windows OSs, including exFat.

The bottom line after all this research is that Symantec needs to keep their mits off our hard drives!!!

Vincent 06-26-13

[Migration User]

SYMEFA.DB is not a useless file, far from it actually. It is a database file that stores information that the SymEFA driver uses in the 12.1 product.

SymEFA is the driver that keeps track of file hashes, Virtual Image Exception status, and more.  Every last feature of SEP 12.1 that relies on a readily-available file hash, such as Scanless and reputation lookup for AV, reputation lookup for PTP (Sonar), Application Control with rules based on file hash, etc, relies upon SymEFA.  Since every last protection feature of the product relies upon SymEFA, and many features rely upon SymTDI/SymNets [IPS etc], both are installed when only Core Files are installed. 

In summary SYMEFA.db is not useless and by removing it you are impacting SEP functionality.

Cameron 06-24-13

[Migration User]

"Once again, I must say it is useless to 95% of all users."

There is a reason that SymEFA is part of the core install files of SEP, the reason being it provides important functionallity that almost every user is going to benefit from, as I discussed previously.

Cameron 06-26-13