On Windows an interrupted mirror that resumes into a bad Content-Range loses the file, where the same sequence recovers it whole on Linux.
The sequence: a crawl is interrupted mid-download, leaving a partial file plus a temp-ref and a cache. A --continue pass re-requests the file with a Range, and the server answers with an unusable 206 (a Content-Range that does not match what is on disk). The engine is meant to reject the range, drop the partial, and re-fetch the whole file (htsback.c:4041, "unusable range -> restart whole file", sets STATUSCODE_NON_FATAL so the slot is retried).
On Windows the restart fails. The resume pass logs "Cache: damaged cache, trying to repair", then "Error attempting to solve status 206 (partial file)" (-5), retries once, and gives up. The partial is removed but never re-fetched, so the file is gone from the mirror.
The trigger is the damaged cache. On Windows the pass-1 interrupt is a hard TerminateProcess (MSYS cannot deliver a signal to a native exe), so pass 1 leaves a truncated new.zip that pass 2 has to repair. On Linux the interrupt is a graceful SIGTERM (sig_finish), the cache is written cleanly, and the restart-whole path works. The partial is 3000 bytes on both platforms, so this is not a buffering difference; the cache repair is what changes the outcome.
Found by running the loopback crawl suite on Windows (#578); 48_local-crange-memresume drives this exact sequence. Skipped on Windows meanwhile. The test also depends on a graceful interrupt that Windows cannot provide, so it needs a Windows skip regardless of the engine fix. Its overflow teeth are UBSan-only, so an MSVC build never covered the original overflow anyway.
Lower priority than #579.
On Windows an interrupted mirror that resumes into a bad
Content-Rangeloses the file, where the same sequence recovers it whole on Linux.The sequence: a crawl is interrupted mid-download, leaving a partial file plus a temp-ref and a cache. A
--continuepass re-requests the file with aRange, and the server answers with an unusable 206 (aContent-Rangethat does not match what is on disk). The engine is meant to reject the range, drop the partial, and re-fetch the whole file (htsback.c:4041, "unusable range -> restart whole file", setsSTATUSCODE_NON_FATALso the slot is retried).On Windows the restart fails. The resume pass logs "Cache: damaged cache, trying to repair", then
"Error attempting to solve status 206 (partial file)" (-5), retries once, and gives up. The partial is removed but never re-fetched, so the file is gone from the mirror.The trigger is the damaged cache. On Windows the pass-1 interrupt is a hard
TerminateProcess(MSYS cannot deliver a signal to a native exe), so pass 1 leaves a truncatednew.zipthat pass 2 has to repair. On Linux the interrupt is a graceful SIGTERM (sig_finish), the cache is written cleanly, and the restart-whole path works. The partial is 3000 bytes on both platforms, so this is not a buffering difference; the cache repair is what changes the outcome.Found by running the loopback crawl suite on Windows (#578);
48_local-crange-memresumedrives this exact sequence. Skipped on Windows meanwhile. The test also depends on a graceful interrupt that Windows cannot provide, so it needs a Windows skip regardless of the engine fix. Its overflow teeth are UBSan-only, so an MSVC build never covered the original overflow anyway.Lower priority than #579.