Best answer by KitView original
Anyone know if the wrdata folder can be cleaned out or deleted? It grows to an enormous size over time.
Already have an account? Login
Login to the community
No account yet? Create an account
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Welcome to the Community Forums.
As you are technical there is another way that avoids the uninstall/reinstall, which involves the review of the 'dbnnnn.db files in the C:ProgramdataWRDATA folder, and then the deletion of selected ones of this file type.
This is not ideal but it does avoid the uninstall/reinstall and also preserves to some extent the rationale for those files; as you may have surmised from the thread these files are the journal files produced when WSA sets a file/app to 'Monitor' and so are important in case WSA has detected a suspicious or an as yet undetermined (in terms of goodness/badness) file/app and then determines it is bad and then needs to roll back its activities, etc., in which case the relevant 'dbnnnn.db' file is required.
The problem is that we cannot easily tell which 'dbnnnn.db' relates to which file/app in the system (there is a way by looking in the Registry but I have lost my notes on that...must try to find them) so the best thing to do is to (i) check all places in WSA where files could be set to 'Monitor', decide whether they are OK or not (and if in doubt leave them as such), (ii) try to work out roughly when a file/app that is set to 'Monitor' was so set & (iii) then go to the C:ProgramdataWRDATA folder and carefully delete all 'dbnnnn.db' files that are either prior to a certain period, i.e., say more than 2 weeks old, on the basis that WSA should have been in a position to sort out if the journal is required or not, or delete everything except for the 'dbnnnn.db' files that are circa the dates that you believe that you 'Monitored' files/apps may have started to be monitored, etc.
The above may seem more convoluted that an uninstall/reinstall, but I have found that it seems to work well, and does give you a better chance of keeping 'dbnnnn.db' files that may be needed; after all an uninstall/reinstall should clear all the files in that folder regardless of whether they are needed or not.
I hope that something in the rambling reponse above is of assistance?
I also check my wrdata folder from time to time, especially after installing new apps. I have had good luck saving a scan log and searching for the xxxx in the dbxxxx.db to see what is lurking about.
I know you are already aware but for BradKilmer's interest, it will look like this : Thu 2015-09-10 07:39:12.0568 Monitoring process C:Program Files (x86)Common FilesAdobeAdobeGCClientAdobeGCClient.exe [40AE8622D89D27C4F704A324CA82AA70]. Type: 3 (XXXX)
From that, I can check the file against VirusTotal and or other means of verifying authenticity and determine if it is safe to delete the .db file, uninstall the app, or wait and see what WSA will ultimately do.
Just one more way.
But of course...I forgot about that way of doing things. :@
I am still looking for the Registry entries approach as that gives an even faster way of determining what is what and when I refind it I will advise back.
The perfect solution to this problem would be to allow me to specify my working folder tree to be off-limits to WSA scans; I never install 3rd party software into my working folder tree and some days I recompile my apps dozens of times.
Is there a way to specify an off-limits folder?
Please see here for more details on this.
Let me know if you think the following steps sound OK:
That sounds about right but as has been said earlier in this thread you need to be very careful as in amongst the files being monitored there could be ones that genuinely need to be because they are 'undetermined' as to whether good or bad.
If you delete the journalling file for one of these and then WS determines that the file is bad, if you have deleted the associated 'dbnnnn.db' file then WSA will be unable to roll back any nefarious actions that the file/app may have been able to take in your system whilst being monitored, and so you will have lost a very useful facility.
Personally I would also add in a check for a list of files/apps, i.e., a control list if you will, that you know are good, i.e., the ones you are creating and only delete 'dbnnnn.db' files if the app in the EXE path matches one of the ones in your control list.
Just a thought.
I keep tabs on WRData directory several times a week. It doesn't take long and you can put a shortcut on your desktop to go right to it. Sometimes I go days and days without any new db files being added. By checking frequently it never grows to more than two or three .db files at most. I can almost tell you when I am going to have them and what they are without even looking at the WRLog or Scan log. For me, it is pretty much a one to one relationship to new or updated apps that I have had an active role in causing. I do a quick check to verify I am on the right track, run the process of verifying the files as I mention in my other post, and if they are ok, I delete the .db files and don't look back. If I can't tell for sure I leave the files for a while to see what WSA determines. So far it has worked for me.
As you say this thread is a great example of how we can all learn from the more senior members of the community and I really appreciate all the time and effort that they put in.
I am careful but also responsible, so I have daily restore points, image backups, file and folder syncs to fall back on. I don't believe in loosing data.
If you are going to gamble you need a fallback plan.
And more importantly, I have 185 GB of unwanted dbNNN.db files in my Recycle bin :)
...and WebRoot came back up without any errors.
I need to put a few finishing touches on the util (along with a short write-up); if anybody is intereseted, I'll put it up for download in a day or so.
Well, I for one would be interested in seeing how this works and whether it is workable in terms of my system usage, even though I do very much subscribe to Daniel's view that the hidden Webroot folders are dangerous place to go if one does not know what one is doing...which is the case for most users.
I cannot speak for Brad but I for one would say that if that is possible then it would be much appreciated.
I have often wondered whether or not they could produce something that, using the Registry entries that track what 'dbnnnn.db' relates to what file/app, could check for any journaling that was no longer required and then purge them, perhaps as part of the System Optimizer, and I know that there is a Feature Request along those line that is open and I believe under consideration.
But as with everything we cannot know how the Development team can or need to move forward etc....I am very sure that they have good reasons for doiing what they do and when..., but perhaps the two can come together to once and for all 'resolve' this small area of contention?
The only "destructive" action now performed is the moving of the dbNNNN.db files to the Recycle Bin.
I also added code to disable the scan if the WRSVC service is running; if WRSVC is running, the user is instructed to shut down WSA before scanning.
I have been absolutely slammed with work this week and I will try to finish this off with an explanitory doc on Saturday.
I am looking forward to it.