Incomplete Article

The determination is arithmetic performed by the client, not a verdict handed down by the server. A yEnc header declares the part number, the part count and the byte length; the decoder tallies what actually arrived and compares the two. A file short by one segment out of three thousand is flagged on exactly the same terms as one short by half its parts, because the comparison is exact rather than approximate.

How the decoder reaches that conclusion

Each encoded part opens with =ybegin and, in a multipart post, an =ypart line naming the byte range that part fills. It closes with =yend, which repeats the size and carries a CRC for the part. Three distinct things fail there. The body can stop before =yend ever appears. The size in the trailer can disagree with the bytes decoded. The CRC can mismatch while the byte count is correct. The first two are truncation; only the third is corruption, and corruption is far rarer than the vocabulary suggests.

Truncation in transit is rarely the cause

NNTP runs over TCP, with TLS above it on most current setups. Both layers detect damaged or reordered data, and both respond by tearing the connection down rather than delivering a mangled body. What looks like truncation is usually one of two other things: a connection closed part way through an article, which the client retries on a different connection, or a stored copy on that spool that was itself short when it arrived during propagation. The distinction is easy to make. A retry that succeeds indicts the connection. A retry that returns the same short body from the same server every time indicts the spool, and no amount of retrying changes the answer.

Three quantities share the same word

Client logs apply incomplete to an article, to a file and to a whole job, and the three mean different things. An article is incomplete when its own decode falls short. A file is incomplete when one or more of its articles never arrived at all, which is by far the more common case. A job is incomplete when enough of its files are short that the set cannot be assembled. The percentage displayed beside a queue entry is the third figure, and it is the only one of the three that predicts whether repair will succeed.

When the shortfall never reaches the reader

Most releases are posted with recovery data amounting to somewhere between five and fifteen percent of the set. Attrition of a fraction of a percent, ordinary on any spool holding articles for years, is absorbed by PAR2 without producing a single visible message. A reader who sees incomplete articles named in a log is looking at normal accounting, not a fault. The event worth reacting to is repair failing afterwards, because that is the point at which the shortfall has exceeded what the poster provided for. Fault sits with the spool that could not supply the article, or with propagation between backbones, never with the local machine; disk and CPU problems produce timeouts and stalls, not short yEnc parts.