From Newsgroup: news.software.nntp

Hi,

when reading[1] I wondered, how does the Cancel-Lock mechanism work when
the cancel is received before the article to be canceled? Wouldnt the processing of cancels have to be delayed until the article has been transferred and seen, defeating the purpose of the delayed feed?

Cheers,
Martin

[1] https://www.eyrie.org/~eagle/software/inn/docs/delayer.html

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

when reading[1] I wondered, how does the Cancel-Lock mechanism work when
the cancel is received before the article to be canceled?

It doesn't work if the cancel comes in before the article.

defeating the purpose of the delayed feed?

Yes. Don't use it if you want to verify cancel locks.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Martin Burmester <martin@burmester.org> wrote:

Hi,

when reading[1] I wondered, how does the Cancel-Lock mechanism work when
the cancel is received before the article to be canceled? Wouldnt the >processing of cancels have to be delayed until the article has been >transferred and seen, defeating the purpose of the delayed feed?

[1] https://www.eyrie.org/~eagle/software/inn/docs/delayer.html

I don't see how there's anything to cancel if the article hasn't yet
been fed. In that case, isn't there some mechanism to run it against the article before feeding? This is one instance in which cancels would
actually accomplish something useful as no user would have yet read the article.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Thus spake "Adam H. Kerman" <ahk@chinet.com>

I don't see how there's anything to cancel if the article hasn't yet
been fed. In that case, isn't there some mechanism to run it against the article before feeding? This is one instance in which cancels would
actually accomplish something useful as no user would have yet read the article.

That's not the problem:

grephistory '<test-6666@killefitz.org>'
grephistory: not found
[news@feeder ~]$ ctlinnd cancel '<test-6666@killefitz.org>'
Ok
[news@feeder ~]$ grephistory '<test-6666@killefitz.org>'
/dev/null

When the article with this M-ID arrives on the server,
it will be rejected as a duplicate.

The problem is that you have a key but no lock to open.
so to speak. The lock is contained in the article that is
meant to be cancelled.
--
-f-a|U-e-u-+ rCo -a-a-|-+-+|U
https://eternal-september.org
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Hello

Am 26.07.2025 um 18:32 schrieb Ray Banana:

Thus spake "Adam H. Kerman" <ahk@chinet.com>

I don't see how there's anything to cancel if the article hasn't yet
been fed. In that case, isn't there some mechanism to run it against the
article before feeding? This is one instance in which cancels would
actually accomplish something useful as no user would have yet read the
article.

That's not the problem:

grephistory '<test-6666@killefitz.org>'
grephistory: not found
[news@feeder ~]$ ctlinnd cancel '<test-6666@killefitz.org>'
Ok
[news@feeder ~]$ grephistory '<test-6666@killefitz.org>'
/dev/null

When the article with this M-ID arrives on the server,
it will be rejected as a duplicate.

The problem is that you have a key but no lock to open.
so to speak. The lock is contained in the article that is
meant to be cancelled.

Exactly. So is this a real problem or should one just not use delayed
feeds when one cares about Cancel-Locks? I mean, its not impossible that
the cancel arrives before the article.

Cheers
Martin

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: news.software.nntp

Hi Martin,

So should one just not use delayed
feeds when one cares about Cancel-Locks? I mean, its not impossible that
the cancel arrives before the article.

Indeed, that's a good point. I had not Cancel-Lock in mind when
suggesting the following example in the delayer manual page:

news.uu.net/uunet\
:!*,control,control.*,news.lists.filters\
:Tm:innfeed!

news.uu.net-delayed/uunet\
:*,!control,!control.*,@news.lists.filters\
:Tm:innfeed-delayed!

I agree that control.cancel should not be delayed by an administrator
who cares about Cancel-Locks (in which case he has very probably also
disabled the process of unauthenticated cancels). I will update the documentation to mention an example with control.cancel not delayed.

Thanks for your message about that problem!
--
Julien |eLIE

-2-aSois sage, || ma douleur, et tiens-toi plus tranquille.-a-+ (Charles
Baudelaire)

--- Synchronet 3.21a-Linux NewsLink 1.2