[PATCH 1/2] storage: Add "filtered" option, to store based on the filter's decision

Julien ÉLIE julien at trigofacile.com
Fri Jan 26 21:33:30 UTC 2024


Adding to my previous message:
>> @@ -643,6 +653,7 @@ SMgetsub(const ARTHANDLE article)
>>               && (!sub->maxsize || (article.len <= sub->maxsize))
>>               && (!sub->minexpire || article.expires >= sub->minexpire)
>>               && (!sub->maxexpire || (article.expires <= sub->maxexpire))
>> +             && (sub->filtered == article.filtered)
>>               && MatchGroups(article.groups, article.groupslen, 
>> sub->pattern,
>>                              sub->exactmatch)) {
>>               if (InitMethod(typetoindex[sub->type]))
> 
> When dontrejectfiltered is set in inn.conf, I am under the impression 
> that the above additional condition will break storage for people who do 
> not use the filtered parameter.
> If I do not have the new filtered parameter set on any storage class, 
> then filtered articles will no longer be stored ("no matching entry in 
> storage.conf").
> 
> I am unsure how to best deal with that.
> If no storage class has a filtered parameter, fall back to discard that 
> condition?

I've gone ahead, and implemented the following rule: if all the storage 
classes have this new filtered key set to false, filtered articles are 
stored in the same storage class as accepted articles.  It is only when 
at least one storage class has this key set to true than filtered 
articles and accepted articles are no longer stored mixed together in 
any storage class.

I hope this is fine for you, Christoph.  At least, it preserves the 
current behaviour on upgrade.
Now committed.  Thanks again for your patch!  (I'll look at your other 
one for Path header fields soon.)

-- 
Julien ÉLIE

« Le cercle est le plus long chemin d'un point au même point. » (Tom
   Stoppard, _Every Good Boy Deserves Favour_)


More information about the inn-workers mailing list