Re: [PATCH] urlfilter: Remove bundled Toulouse blacklist

[p27m <p27m@orange.fr>]

Hi Adolf,

Thank you for following up on this.

The |blacklists.tar.gz| Toulouse blocklist currently present in the 
IPFire repository dates back to 2015 and is one of the remaining parts 
inherited from the old IPCop URL Filter add-on. It is not part of the 
SquidGuard package itself.

Replacing |blacklists.tar.gz| with a newer version would indeed be a 
viable solution to the current problem with directories being replaced 
by symlinks. It should work without any code changes.

However, this would only be a workaround for the underlying problem. 
There is no guarantee that the structure of the Toulouse blocklist will 
not change again in the future, in which case the same problem could 
reappear.

I also wonder whether it makes sense to continue installing a blocklist 
which may become obsolete again relatively quickly, or potentially 
disappear altogether.

There is already a blocklist maintained by IPFire at:

https://dbl.ipfire.org/lists/squidguard.tar.gz

It might therefore make more sense to use this list as the bundled 
default instead.

However, this would not address the problem when restoring a backup 
containing a Toulouse blocklist that was previously in use by the user. 
The restore process could still encounter the same directory/symlink 
conflict.

The solution I proposed is intended to address both aspects: removing 
the obsolete bundled Toulouse list and making the restore process safe 
in case an older Toulouse list is present in a backup.

That said, you are the experts on the IPFire codebase and its long-term 
maintenance, so I will of course leave the final choice to you.

Regards,

Philippe


Le 27/09/2026 à 12:44, Adolf Belka a écrit :
> Hi All,
>
> I am following up on this as it has not had any follow-up for a while..
>
> If there is a concern on the potential impact of not having any 
> bundled Toulouse blocklist in the URL Filter, an alternative would be 
> to have a newer version of the Toulouse Blocklist that includes the 
> symlinks approach that Toulouse started using earlier this year.
>
> Would that be a viable approach? That would then keep the current 
> default status of having a blocklist defined but using one that has 
> the symlinks and therefore does not end up with the problem of trying 
> to create a symlink with the same name as an existing file.
>
> Regards,
>
> Adolf.