Hopefully others know. I haven't seen that yet.
From your image, it looks like the transfer speed is really slow. Are you on wireless internet? The other thing(s) I can think of to ask is

You're not skipping image file verification, are you?
You don't have transfer speed limits checked in manual preferences, right?
Do you have other tasks, projects, or PC programs that might me holding up your internet traffic?

good luck, and I hope others know more about that


[actually, the transfer speed might be ok the way it is, I just noticed mine transfers even slower ( <3K bps at times), even though my internet connection is 100.0M bps)

+1 Sgt Joe - When your connection gets dropped (most often this it is your ISP and/ or your local PC) BOINC has to recheck the last bits sent when it reconnects and sends more. If this happens a couple of times on the same transfer (especially on small files) you will see what appears to be overruns. You would think Berkeley could fix this in the BOINC agent but they never have.

Thanks for all replies. I just ran across a script in C which converts DOS to UNIX and the other way around. The problem with the difference in the two is the CR/LF or CR control characters. Some scripts are no problem, yet others are for reasons of printer compatabilities.

I only mention the above as an example of how scripts differ across the cloud of possibilities as no one size fits all

Perhaps it's a simple lack of trapping EOF (end of file) markers or not.

In any case the traffic density is surely a factor as I know the problem is more frequent when the web is loaded with packets and the BW is low.

As a temporary measure, I simply "Abort" the troublesome task since they mostly are very large files (over a MB) and interruptions occur in my dialup (56K) line connection.

Happy crunching!

If a download is interrupted before finish, the BOINC-client will discard the last 2 KB transferred before saving the file to disk. On next download-try, the client tells the server how much of the file is already present, and the server should only send the remaining part. But, the WCG download-server intentionally overlooks the client-info, and always re-start the download from beginning. Since client isn't aware of this, the download will continue past 100%. After getting the whole file in a single download-attempt, the client will correctly discard the previously-downloaded portion of the file and use only the "correct" file.

While download-resuming doesn't work for WCG, upload-resuming does work.