Solved

Controlling WRData folder size - help needed



Show first post

195 replies

Userlevel 7
Hi VirtualFM
 
The best thing in the circumstances is to follwo the advice given in this thread which is essentially to Open a Support Ticket and get the Support Team to review and whitelist, where appropriate, those items on your system that are identified as 'Undetermined (prefixed with a [u] in the Scan Log) as these are the items that will be journalled and therefore create the .db files.
 
Alternatively, one can follow the guidance provided to allow the .db files to be associated back to the files that are being monitored and if one knows that these are safe then to (i) change the 'Monitoring' status to 'Allow' & (ii) delete the relavnt .db file(s).
 
Am afraid that the thread is pretty complete in terms of options until the Developemnt Team decide to provide a more permanent 'solution'.
 
Regards, Baldrick
 
Userlevel 1
OK, thank you. I guess that's the cunningest plan I can have now!
Userlevel 7
Hi VirtualFM
 
Indeed...it does sound like it. ;)
 
If you have trouble locating the suggested approaches just let me know and I can report them here for you.
 
Regards, Baldrick
Userlevel 1
i have problems with my sistem by his fault, the webroot curse flattening HDD.25gb WRData? Very little space. What I can do?
Userlevel 7
@ I've created a ticket on your behalf with our Support Team. They'll be reaching out to you shortly!

Cheers,
You're complaining about a 2 GB WRData folder? Mine was 110 GB!
Userlevel 1
I think the solution is not a tickete in a dark support room for the public, it is incomprehensible, the solution is to make permanent fix the bug in a new AV installer, it would even be better to never create backups. Or an option to disable it within the GUI. I'm sorry, I have 2 licenses that I have omitted to use because of this problem. I would also like the GUI to be able to expand the size of the window to manage the options inside. Is too small to manage the networks on his firewall. I like webroot, protects very well againts unknow programs, and has a very strong armor with capcha and passwords inside panel, meanwhile I will keep waiting for those improvements, and it hurts not being able to use it. Many blessings and best wishes for all. Atte Patricia.
Hello @, and a warm welcome to Webroot Community Forum.
 
Sorry to hear about your problem with the WrData folder :8
 
Your suggestion:
 
@ wrote:
...never create backups. Or an option to disable it within the GUI...
 
I’m really sorry to say, but this is never going to happen :8. Why? Because it would fundamentally compromise Weboot’s architecture.
 
Webroot’s uniqueness is this: it is designed to not only stop bad executable files that are known to be bad from harming your computer, but also to stop bad executables that are not yet known to be bad from harming your computer. How? By closely watching every unknown executable file and journaling every change it makes (while at the same time continuing to protect all your private data from theft).
 
If and when a file is found to be bad, Webroot will kill it and, using the journaled data from the WrData folder, reverse all changes that it has made to your computer. And if it is found to be good, Webroot will whitelist it and remove all the journaling data from the WrData file.
 
Webroot is the only security programme I know that does this. That is why I think it is so good.
 
However, because of that, sometimes people like you get a very large WrData folder. What is the answer? I think that perhaps Webroot should introduce a mechanism that signals to them when the WrData folder of a device exceeds a certain size, and then manually check which executables from that device are being monitored by the Cloud, and whitelist those files where appropriate. Just my opinion…
 
So yes, I agree with you when you say:
 
@ wrote:
...the solution is to make permanent fix the bug in a new AV installer...
 
But maybe there is a reason why it is not practicable for Webroot to do this?? That, I don't know.
 
If ever your WrData folder grows again (and I hope it doesn't!), ask Support to look at your problem and they will whitelist (where appropriate) the executable files that Webroot is monitoring on your device.
 
Hoping you will continue with Webroot. Sadly, it sounds like you may have already given up [=abandoned] Webroot because of this somewhat annoying problem.
 
I hope this helps 😃
Userlevel 1
I am also sorry but I'll have to jump off this WR bandwagon: the OP is dated 3-4 years. And there is still:

1) no solution for the ever-growing files, and the associated I/O performance hit

2) No SIMPLE way to stop this journalling for a file, without contacting WR tech support. Setting the file from monitor to allow does not cut it, files are still generated for the same process.

Shame for this program...
Userlevel 1
It would be WAY LESS  annoying if we could redirect log files into a temp file somewhere else, instead of being somewhere in the default C: drive, as most of us have Terabytes of free space somewhere else waiting to be filled with useless logs.

Anyway, my subscription has ended and I am not going to resubscribe. Not exactly because of this problem but becasue of several other problems. I will post when I have the time and stamina for it.
@ wrote:
It would be WAY LESS  annoying if we could redirect log files into a temp file somewhere else, instead of being somewhere in the default C: drive, as most of us have Terabytes of free space somewhere else waiting to be filled with useless logs.
 
I agree. But I completely disagree about the log files being "useless". They are FAR from useless (see my post above).
 
If and when you find the stamina, we would be genuinely interested in knowing your reasons for ending your subscription.
Userlevel 1
You are right about the "uselessness". They are obviously important for analysis from Webroot's point of view. I meant useless for the user, who doesn't want to be bothered with them in normal usage. If this was not an issue the user wouldn't even know about the existence of those log files. We do because they are interfering with our daily routine and messing up our workflow. If they were "transparent" most of us wouldn't care less about them.
Very few users have problems with unreasonably large WRData folders. But for those who do, I can imagine it can be annoying, more particularly if it is interfering with efficiency due to lack of disk space and/or possible performance issues as a result.
 
Will certainly be interested in hearing your (other) reasons for discontinuing with Webroot when you find the time.
Userlevel 7
Hi monstertruckpa
 
Welcome to the Community Forums.
 
If I may pick up on the point you made about the non resizable nature of the WRSA UI...this is due to the way that & in what WRSA is written in as a programming language. IT was designed from the outset to have as small a footprint/impact on the computer it is installed on, and in terms of the .exe that does most of the work it is remarkable that so much is done by something that is barely over the 1Mb mark in terms of size.
 
Now whether this policy or approach will change in the future I do not know but I believe that there a feature request already lodged (HERE) in the Ideas Exchange which you could support/add you comments to. The Development Team regularly review the ideas & features requested and if enough support is garnered there is a chance that they take the idea onboard.
 
Hope that helps?
 
Regards, Baldrick
Userlevel 5
Hi monstertruckpa
 
Welcome to the Community Forums.
 
If I may pick up on the point you made about the non resizable nature of the WRSA UI...this is due to the way that & in what WRSA is written in as a programming language. IT was designed from the outset to have as small a footprint/impact on the computer it is installed on, and in terms of the .exe that does most of the work it is remarkable that so much is done by something that is barely over the 1Mb mark in terms of size.
 
Now whether this policy or approach will change in the future I do not know but I believe that there a feature request already lodged (HERE) in the Ideas Exchange which you could support/add you comments to. The Development Team regularly review the ideas & features requested and if enough support is garnered there is a chance that they take the idea onboard.
 
Hope that helps?
 
Regards, Baldrick
Userlevel 7
@, I've created a support case on your behalf with our Team so they can properly classify the files that are being monitored excessively.
 
Do let us know once you've worked with them to resolve this!
Userlevel 7
Hi kliebor
 
This happens to us all and is most likely due to changes to certain files and/or executables when an application receives a patch or update...some of which happen silently so one would never know that they have occurred.
 
Whilst Webroot attempts to review and whitelist all file changes that occur daily it may well miss some and as a result we get some well known applications' files/exes being marked as undefined and therefore monitored.
 
The thing is that all monitored files are rechecked at each scan and once a file is determined to be good, i.e., whitelisted, the monitoring will stop. But what does not seem to happen is the removal of the journal file created by the monitoring process. I believe that they are supposed to be kept for a pre-determined period of time and then automatically removed/deleted but to be honest I have never seen that happen.
 
Hope that helps explain things a bit?
 
Regards, Baldrick
 
 
Userlevel 5
Thanks alot, and I did submit a ticket before I posted that to support with the full log attached, I just put things here as well because I know sometimes it helps get attention.
So the "Solution" after 4 years is:
 
1) Open a support ticket - so I can manually try to whitelist something and waste my time due to the fact I am developer and the exes filling this up are probably the ones I am writing.
2) Uninstall - not an option as I am a business user who gets this pushed down by GPO
3) Manually trawl thru an 11MB text file manually cross referencing xxx with xxx.db?
 
Honestly; that's pretty shoddy really.
 
How about an automatic disk cleanup util added to the UI and protected by the normal "Do you know what you are doing?" Enter a Captcha and a bunch of disclaimers to cover yourselves and then everyone will be happy and this 17+ page epic can end.
 
 
Userlevel 7
Hi uwantfries
 
Welcome to the Community Forums.
 
Thank yo for your views on this. Yes, it is frustrating but having said that I suspect that the issue is being reviewed and an appropriate approach developed. At one stage it was mooted that the process had been changed so that any no longer required .db files would be cleared after 30 days after the journaled file was determined to be 'good' and therefore no roll back would be required...but as far as I can tell there has been no evidence of this...so I am wondering if I imagined it.
 
Perhaps @ or @ can make some enquiries for us behind the scenes to find out how all of this should work and what, if any, changes are in the offing?
 
Regards, Baldrick
Userlevel 7
@ wrote:
So the "Solution" after 4 years is:
 
1) Open a support ticket - so I can manually try to whitelist something and waste my time due to the fact I am developer and the exes filling this up are probably the ones I am writing.
2) Uninstall - not an option as I am a business user who gets this pushed down by GPO
3) Manually trawl thru an 11MB text file manually cross referencing xxx with xxx.db?
 
Honestly; that's pretty shoddy really.
 
How about an automatic disk cleanup util added to the UI and protected by the normal "Do you know what you are doing?" Enter a Captcha and a bunch of disclaimers to cover yourselves and then everyone will be happy and this 17+ page epic can end.
 
 
We have two improvements coming down the pipe:
  1. The removal of old database files after they have been whitelisted
  2. Resolving the overlogging of override files in wrlog.log
These updates are tentatively set for version 9.0.19 but this is always tentative.
Userlevel 7
Badge +56
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Userlevel 7
@ wrote:
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Further enhancements around database file cleanup is on the table for 9.0.19
Userlevel 7
Badge +56
@ wrote:
@ wrote:
@ it's been in a WSA update so what happened? https://community.webroot.com/t5/Product-Releases/PC-Agent-release-notes-for-version-9-0-11-70/m-p/264182
 
Version 9.0.11.70 (Released August 15th, 2016)
Improved
  • Remove obsolete databases.
  • Bug fixes.
 


 
 http://answers.webroot.com/Webroot/ukp.aspx?pid=10&app=vw&vw=1&login=1&json=1&solutionid=857#901362
 
Further enhancements around database file cleanup is on the table for 9.0.19
This has been going on since 2013 (4 years) so I hope the developers finely get it right? Seriously! :)
https://community.webroot.com/t5/Webroot-SecureAnywhere-Complete/Controlling-WRData-folder-size-help-needed/td-p/69357
Userlevel 7
Completely agree with you on this one, Daniel...I personally cannot understand why the clean up after whitelisting is so challenging...but we are here we are and so we can, indeed, only hope that this time the feature will work as we all hope that it will. :8

Reply