Skip to content

Brave-browser creates 800-1000 temp folders a week and does not remove them chrome_url_fetcher* when updating adblock #46202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
chris451gh opened this issue May 20, 2025 · 2 comments
Labels

Comments

@chris451gh
Copy link

When operating the Brave browser, in several versions of windows 10, with the adblock enabled (its embedded not an extension one can remove) brave attempts to update the adblock block lists aprox every hour and a half. In brave the only control available is which blocklists are enabled. It warns enabling more than a few slow down brave.
It (brave or braveupdate) creates in a temp folder 1 2 or 3 at a time (program files) or (c:\windows\temp) a folder beginning with
chrome_url_fetcher with a long unique hex suffix. It downloads an update file from adblock plus to this folder then decompresses these files to a working folder under the brave program folder. I tracked down the files after they were moved out of the temp folder.
It is downloading Json and other files in a zip format archive with no suffix, with an internal prefix indicating a compressed archive. These files are moved to the brave program folders, and are replaced if newer, and remain the same if not updated. The downloaded files are rapidly or immediately removed from the chrome_url_fetcher folder which is left empty. Note these are not removed so they accumulate at the rate of the update, approx 90 minutes. At a rate of 4000-5000 folders a month, these folders begin to bog down and slow down any windows system as it takes longer to find create delete temp folders because explorer must search past the empty folders.
Within this file set is indicated an expiration time/date, which is ignored by brave, it still downloads all these files anyway triggered by an internal task timer, this activity can't be found in the windows task scheduler.
The adblock plus is embedded in the brave browser and cant be removed but all the lists may be able to be disabled.
To locate these folders on your system
do a whole disk folder search for Chrome_URL_fetcher* or use an app like 'everything' at voidtools and it will list all the folders.
You will find them all empty, delete all of them.
This has been observed from other browsers but not to this extent.
To track down the downloaded files:
Using the time date search, make note of the date and time of the latest chrome url fetcher folder. Now search in the brave folders for that same date/time.
You will find a file of approx 500k with a long alpha numeric name and no extension, which can be opened with file decompressors that handle .zip files. In that file is the blocklist.txt and some json files.
Within each blocklist .txt file is an expiration date.
The suggested fix somewhere in brave code:

  1. observe the expiration date of the blocklist files to wait to check again for updates.
  2. after a download remove the folder chrome_url_fetcher*????????? which is a unique folder.
    3)perform a cleanup of any empty chrome_url_fetcher*????????????? folders in temp.
@ghost
Copy link

ghost commented May 20, 2025

This is an issue with Chromium. I see the same thing with Edge and others in computers that don't use Brave. Since Brave downloads the lists as components, it makes sense for it to do that 'more often' it seems, because filter lists get updated many times a day, but it doesn't mean you won't see hundreds from Edge and others.

Brave could do something about it, but it would be better if it was fixed in Chromium, because sometimes these folders are created even at program files level and not even in the Temp folder.

Anyway it is how it works, you can see in the Chromium source code around here:
https://source.chromium.org/chromium/chromium/src/+/main:components/update_client/url_fetcher_downloader.cc;l=45;drc=2888031a21ee6b8d9ece12439903cec06c018f8d

@chris451gh
Copy link
Author

Thanks for the find, as seen there it will only delete the folder upon error but otherwise it gets left behind.
O-Kay I'll leave an issue in that repo thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants