some rare Spotlight result files won't upload

Probably hundreds of Spotlight result files are uploading without difficulty.  However, I have (so far) three file that just won't complete the upload.  The odd thing is that they stall at exactly the same point and all retries fail.  So, for example, the result file h1_0209.35_O2C02ClrIn0__O2MDFS2_Spotlight_0209.50Hz_56_0_0 has retried 27 times and always stalls at 6.86% progress.  (There is another similar file that has retried 39 times and stalls at 20.69% but assuming it is the same underlying issue let's just focus on the first case.)  "Knowing" that the upload is going to fail, I have used a packet capture utility (tcpdump in Linux) to save a log of the entire session.  And that log file, roughly 500K bytes, is available if needed.  All appears to proceed normally in establishing the TCP link and getting the file data flowing.  The host is sending data packets with advancing sequence numbers; the server begins "ack"ing the packets but does not get past (ack 4304  win 37648).  From that point onward the host continues the data stream but DOES NOT exceed the server's receive window.  The server's ack's are always "ack 4304" with the "win" parameter gradually increasing to 65160.  Eventually the server begins replying with the "selective ack" header showing 5752:23128 (for example) with the upper bound increasing with each ack packet.  Within reasonable time, 0.15 second, the host resends the "lost" data packet, seq 4304:5752, and then resumes the data stream where it left off.  The server continues to reply, ack 4304 with the sack block upper bound increasing.  This pattern, host resending the 4304 packet then resuming the data stream, server responding with ack 4304 and enlarging sack block boundary.  The process eventually ends when the host approaches the receive window size, keeps resending the 4304:5752 packet at increasing timeout intervals, and both ends eventually give up and close/reset the TCP link.

I have seen other uploads stall on the first attempt (reasons unknown) but always run to completion on the second (or at most third) retry.  The consistency of this upload always stalling at byte/block 4304:5752 certainly looks strange.  There are, of course, lots of potential software failure points:  the BOINC file upload process; the host TCP flow manager; the server file receiver.  One's imagination goes wild!  A byte sequence in the data stream that is interpreted as an "escape" sequence (at any node in the transfer path)?  In a gzip compressed file any byte pattern can eventually occur.

One of the stalled uploads, the one already retried 39 times, has a deadline of August 28 (Friday) so I suppose it will be cleared from the upload queue at that time.  The one I've discussed here has a deadline of August 30, so it will be around for a few more days if there is anything useful to try to get it uploaded, or to further diagnose the problem.