Zero-Byte File

The size is the diagnostic. A file that downloaded and decoded has bytes, even a badly damaged one, so zero means either that nothing ever decoded or that something after the download stage created the file and did not fill it. Those two possibilities sit at opposite ends of the pipeline and share no causes, which makes this one of the easier failures to place.

Where in the pipeline it can appear

At the download stage, a zero-byte result means every segment listed for that file returned not-found. The log shows articles missing at or near one hundred percent for that file, and the job's transferred byte count falls far below the release size. At the post-processing stage, the download completed normally and the transferred figure matches, but extraction, a move or a script produced an empty file. Comparing what the queue recorded as transferred against the size of the output settles which of the two occurred, and it should be the first thing looked at, because everything downstream of that comparison differs.

Release age narrows a download-stage case in one step

An old release with zero-byte files is an expiry case: the articles aged past the retention window on the spool queried. A recent release with the same symptom points at removal, most often between the indexer's scan and the download attempt, which is why an NZB that looked healthy in a listing can return nothing an hour later. A posting that never propagated to that backbone is distinguished from removal only by asking a source on a different backbone. The whole-file rather than partial nature of the loss is itself informative: parts scattered across many files suggest attrition, whereas an entire file absent suggests it was never on that server.

Zero bytes after a job reports success

When the download is intact and the output is empty, the causes are local. Extraction that ran out of space part way through can leave a created but unwritten file. An interrupted move between filesystems, which is a copy followed by a delete rather than an atomic rename, leaves the destination empty. A post-processing script that redirects output over the file it was meant to read truncates it instantly. Free space on the destination volume and the client's own post-processing log are where this is resolved, and the provider is not involved at any point.

Small files that are not failures

Not every tiny file in a completed folder is a fault. Padding files are posted deliberately to alter a release's size profile and carry no content by design. Sample and placeholder files can be a few kilobytes while bearing a name suggesting the full item. Some clients create zero-length placeholder files during direct unpack and populate them as extraction proceeds, so a file observed at zero bytes while a job is still running is frequently just work in progress rather than evidence of anything.