a full disk is treated as an ordinary per-file error: the run continues and burns bandwidth it cannot write

[LeyckerS]

When the destination fills up, every remaining file is still extracted, downloaded in full, and only then fails on the write. The run does not stop and the user is not told.

Observed

58 links, destination drive with no free space left:

  Total links    : 58
  Completed OK   : 12
  Failed         : 46
  Total data     : 4.36 GB
  Median DL time : 52.9s

The GUI meanwhile reported 16.58 GB transferred over 4m 50s. Every one of the 46 failures carries the same note:

  1    Halo_Campaign_Evolved_...    0   0    0.0    0.4   236.1    —  fail
       → error att 1: [Errno 28] No space left on device
  2    Halo_Campaign_Evolved_...    1   0    0.0    0.5   236.5    —  fail
       → error att 1: [Errno 28] No space left on device
  3    Halo_Campaign_Evolved_...    2   0    0.0    0.3   236.2    —  fail

Each of those spent 236 seconds downloading before failing on a write that could never succeed. Roughly 12 GB pulled off the network and discarded.

Cause

ENOSPC is not distinguished anywhere — grep -n "ENOSPC\|No space" moon_download.py returns nothing. It lands in the catch-all:

except Exception as e:
    err = str(e)
    rec.notes.append(f"error att {att+1}: {err}")
    if att < DL_INNER_RETRIES - 1 and ("ContentLengthError" in err or "not enough data" in err.lower()):
        await asyncio.sleep(0.5 * (att + 1))
        continue
    return False, err, downloaded

It correctly avoids the inner retry, then returns a per-file failure and the worker moves to the next link — which will fail identically, because the disk does not empty itself between files.

The note goes to rec.notes, which only reaches the report after the run (#99), so nothing on screen ever says "disk full". The user sees files failing for no stated reason.

What is needed

ENOSPC is not a per-file problem. It is a run-level, non-recoverable condition and the only correct response is to stop:

• Detect it specifically — isinstance(e, OSError) and e.errno == errno.ENOSPC rather than matching on the message, which is localised (the report above is from an Italian Windows and reads "No space left on device" only because Python normalises it; other paths do not)
• Abort the run rather than continuing to the next link
• Say so unmistakably, in the live log and not only in the report: which folder, how much was needed
• Leave the .tmp files alone — they are resumable once space is freed, and the run had 46 of them

Worth deciding and stating in the pull request: whether in-flight transfers are cancelled immediately or allowed to finish. Cancelling recovers the bandwidth sooner; finishing means fewer half-files. Either is defensible.

Acceptance criteria

• A run that hits ENOSPC stops instead of attempting every remaining link
• The reason appears on screen while it happens, naming the destination folder
• Existing .tmp files are preserved for resume
• Detection is by errno, not by string matching
• A regression test with a write that raises OSError(errno.ENOSPC, ...) — no network needed, tests/test_resume_200.py shows the pattern for faking the response surface

Environment

Windows 10, Python 3.14.6, destination on a drive with 0 bytes free of 931 GB. Found by running the program.

[shard872]

I’d like to work on this. I’ll treat ENOSPC as a run-level fatal condition, preserve resumable .tmp files, surface the destination in the live log, and add a focused regression test for errno-based detection. I’ll also make the cancellation choice explicit in the PR and verify that no queued links continue after the fatal write error.

[LeyckerS]

@shard872 — yours, assigned. Apologies for leaving the assignment off until now; the issue read as free in the listings while you already had #150 open, which is my bookkeeping error and not yours.

Your plan in the comment above is what you built, and I have reviewed and approved #150 — errno-based detection, run-level abort, the folder named in the live log, .tmp preserved. The only thing outstanding is a rebase, because I merged #149 (#65, Stop) into the same region of _do_dl first. Details and a map of exactly what moved are on the PR.

[LeyckerS]

Fixed by #150, merged — thanks @shard872.

The first ENOSPC is now detected by errno and published as a run-level fatal state, so queue intake and retries stop instead of continuing to fetch data that cannot be written. The live log names the folder and the shortfall. Interrupted files keep their .tmp and stay resumable, and only the URL that actually triggered it is recorded as failed — the files stopped as a consequence are reported aborted rather than each being blamed for a disk problem, which was the reporting complaint in this issue as much as the bandwidth one.

Two details from the patch worth recording here, because neither was in the issue and both are the kind of thing that gets "simplified" away later:

Writes loop over a memoryview. On a nearly-full disk write() can return a short count rather than raising, so a single unchecked f.write(data) silently truncates the file. The loop is what makes the byte accounting in the error message true.

The disk-full state is deliberately separate from the stall-kill state. Reusing kill_evt would have made a full disk look like a stall, and stalls are re-extracted by design — the run would have retried its way through the same failure. This is the same reasoning behind the stopped status added in #149.

In v4.1 when it ships; on main now.