SETI@home has implemented 'Redundant result - Cancelled by server' technology - if a quorum is filled and work validated, messages are sent to host(s) with the same WU 'abort if not started'.
During outage recovery on a busy/short WU project like SETI, it is possible that a WU can be validated and assimilated while the third quorum member (me, in this case!) is still trying to download the datafile through congestion/backoffs.
After assimilation, the datafile is quite properly deleted from the server download fanout, and the host's transfer is doomed to fail forever with 'file not found' retrys.
Once the host gets into this state, it seems to inhibit all work fetch for that project, until the offending transfer is aborted by user intervention. It will rapidly run dry.
When the server abort is issued and acted upon, presumably there are two actions:
1) Remove from task list after report
2) Delete datafile from disk
There needs to be a third:
3) Cancel any pending transfer for the datafile
