An update purge deletes the children of a page that failed to fetch

[xroche]

On --update the engine unlinks what the previous mirror had and this run did not write. A page that gives up after its last retry keeps its copy (#746) but is never parsed, so its links never reach new.lst, and the purge reads that gap as the site dropping them: one dropped connection on a hub page costs its whole subtree, silently, while the run reports success. An HTTP error already escapes this, being masked to a 304 and recovered from the cache. A transport failure has no such path.

The purge now holds off for the run when a link that could carry links fails to transfer, keyed on back_transfer_failed() so it cannot drift from the predicate that decides whether the copy is kept. A mangled Content-Encoding, a bad chunk length, a disk write error and an aborted external wrapper all report STATUSCODE_INVALID, keep their copy, and now keep their children with it. Two cases deliberately do not hold: an answered HTTP error, which is recovered and re-queues its links, and a page the size cap skips, whose own copy #746 drops so its children go with it rather than being stranded. The guard also requires that the previous run actually mirrored the page, since only then is there a subtree at risk. Typing the link by its savename instead let any new permanently dead .html link disable the purge on every run.

Masking the failure as a 304 was the alternative and does not work this far down the loop: that masking sits ahead of back_finalize, and doing it at the give-up point would disarm the "no data transferred, restore the previous session" rollback, so a mirror whose host had vanished would report success.

httrackp gains one field at its tail, live state copy_htsopt leaves alone. It lands in the padding after wizard_filters on LP64, so sizeof is unchanged there; on ILP32 the struct has no trailing padding and grows by four bytes, as every earlier tail field did. size_httrackp is asserted against sizeof at each entry point, so a stale-header consumer aborts rather than corrupts.

Known gap, not fixed here: a failed fetch writes no cache entry, so a hub failing on two consecutive runs has no previous entry the second time and stops holding the purge.

Test 348 drives five shapes past the guard and reads hts-changes.json rather than a log line, the two boundaries above among them. Found by the httrack-android session's overnight robustness audit, reproduced against 3.49.23.