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
when reading[1] I wondered, how does the Cancel-Lock mechanism work when
the cancel is received before the article to be canceled?
defeating the purpose of the delayed feed?
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.
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.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 52:29:52 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,384 |
| Posted today: | 1 |