How to prove a copy is intact, and what to do when it is not.
Two sides to this, and they are different jobs:
- You downloaded a share and want to know your copy is good → Checking a download
- You published a share and want it to still work next year → Keeping a published share alive
Checking a download
What already happened without you asking
Every piece is verified as it arrives. Each one carries a hash from the published catalogue, and a piece that does not match is refused and re-fetched. A download cannot silently complete with corrupt content from the network.
Then, at the end, there is a second pass that reads the files back off your disk and checks them. You see it as:
Download finished — all 412 GB are on disk. Now checking every byte reads back correctly…
with a rate and an ETA.
"If every piece was already verified, why the second pass?"
A fair question, and the answer is that the two passes catch different failures.
The first pass proves the network delivered the right bytes. The second proves your storage kept them. Between the two sits everything that can go wrong after a byte is correct in memory:
- a drive with a failing sector, or one quietly remapping
- a network share that accepted a write and dropped it — common on Wi-Fi, and the reason this pass exists at all
- a filesystem or USB enclosure that lies about having flushed
- RAM that flipped a bit after the check but before the write
None of these are exotic. The network-destination case in particular shows up regularly, and it produces a download that reports success and contains bad files. That is the worst possible outcome, and the read-back is what prevents it.
Can it be skipped?
Yes, and it is a legitimate choice on hardware you trust.
Settings → Performance → Final check of very large files:
| Option | Use when |
|---|---|
| Automatic (recommended) | Default. Decides per file by size. |
| Check during the download | The final pass is painful on your destination and you would rather pay for it as you go |
| Check after the download | You want one clean pass at the end |
| Skip the final check | Fast local NVMe you trust, and you want the time back |
Check during the download is the better answer for most people who find the final pass slow. It does the same work, overlapped with the transfer, so the wall clock improves without giving up the check.
If it is slow, understand why before switching it off: the pass is limited by how fast your destination can be read, so a slow figure is telling you something true about your storage. The speed test measures read and write separately and will say so — When something is wrong.
Checking on demand, later
The share's Verify & Repair tab has two levels.
| Checks | Roughly | |
|---|---|---|
| Verify (quick) | Every file exists and is the right size | ~30 seconds per 100,000 files |
| Verify (full SHA-256) | Every byte, hashed and compared to the catalogue | ~3 minutes per 100 GB |
Quick catches the common cases — a deleted file, a truncated one, a sync that half-finished. It reads directory entries, not content, so it is fast at any size.
Full is the real proof. It re-reads and re-hashes everything, so it is limited by your disk. Worth running when you are about to rely on the data, when a drive has misbehaved, or before deleting the source of a share you published.
Anything wrong is re-queued for download automatically. Verify is also repair: missing and mismatched files are fetched again, and you do not have to work out which. A one-click version is on the Dashboard for each imported share.
If files have drifted from what the app expects, an amber restore missing files banner appears and does the same thing.
Keeping a published share alive
Usenet retention is finite. A share you published is a set of articles at your provider, and articles do not live forever. For anything you want readable in a year, there are two controls.
Redundancy — extra copies, posted up front
The Redundancy tab on your folder.
By default the app posts 3 copies of every piece of content. Losing one or two copies of a piece costs you nothing, because the others are still there.
| Control | Does |
|---|---|
| Duplicate (N) Copy | Post N further copies of every data piece |
| Listed in core index? | Yes — listed makes copies part of the share. No — spare keeps them as repair material only. |
| Check | Report current health |
| Repair | Re-post what has gone missing |
Health reads Healthy, Under-replicated or Not posted yet.
The catalogue, the access layer and the manifest have their own redundancy settings in Settings → Advanced. These are small and cheap to duplicate, and they are also the pieces whose loss is fatal — without the catalogue there is no share at all, no matter how healthy the content is. If you raise anything, raise these. See Recommended settings.
Verifying that your articles are still there
Files tab:
| Button | Does |
|---|---|
| Verify Segments (all) | Ask your provider to confirm every article is present |
| Verify Selected (N) | The same for a subset |
| Retry Failed Verifications | Re-check only the ones that failed |
| Retry Failed Uploads | Re-post only the ones that failed |
The two retry actions are cheap: no re-index, no full re-verify, just the failed subset.
Run this occasionally on shares that matter. It is the only way to find out that a share has quietly decayed before a recipient does.
Right after publishing, some failures are normal. Providers can accept an article and take a little while to make it retrievable. Wait a few minutes and Retry Failed Verifications before concluding anything is wrong.
"A share reports missing or expired articles"
The common one. What it means depends on which side you are.
You are downloading someone else's share. Nothing on your side can fix it. The pieces are gone from Usenet, and no amount of retrying conjures them back. Tell the owner — they can repair from redundancy or re-publish, and only they have the source files.
It is your own share. You have two routes:
- Redundancy → Repair. If spare copies survive, this rebuilds from them. Fast, and no re-upload of what is still healthy.
- Re-publish the folder. Needs the original files still on your disk. Mints a new link, so recipients need it. See Upload and publish.
Preventing it next time: more redundancy on content you care about, a periodic Verify Segments, and awareness of your provider's retention window. A share untouched for years on a provider with shorter retention will decay; one with generous retention and 3× redundancy is durable.
What none of this can fix
Worth being clear about the limits.
A forgotten password. Not a verification problem and not recoverable. See Public, password and private shares.
A share whose catalogue articles are gone. If the pieces holding the catalogue have expired and no redundant copy survives, the share cannot be opened even though the content articles may still be present — there is nothing left to describe them. This is why catalogue redundancy is the one worth raising.
Content the owner has deleted and never republished. There is no central copy. Usenet holds what was posted; if it has expired and the owner no longer has the files, it is gone.