#171 DCC "rollback" before resume

[Anonymous]

DCC transfers should not resume right from the last bit
of data to prevent corrupt files. The last "X" bytes should
be discarded and then resumed, as often the last
segment of data transmitted just as the connection is
broken is corrupted. It should be possible to modify
value of "X" (from say 40b to 512kb).

submitted by happy@tasmail.com

[Peter Zelezny.]

Logged In: YES
user_id=5012

The last few bytes should not get corrupted. You are saying
this happens "often" - very hard to believe.

[Alzheimer]

Logged In: YES
user_id=1024324
Originator: NO

I had corruption with DCC resumes pretty often, for example it would resume at byte X but instead of actually resuming, it would write the beginning of the file at byte X all over again. However I doubt this is xchat at fault, I think it's more likely that the other side claimed it was able to do a resume but sent crap data instead. I have a DCC download script, and because of resume / corruption issues I made it so that it deletes the local file, if the offered file has a different size. So instead of a resume it does a redownload. As the script prevents fetching files I already have altogether (long as name and size match), a little wasted bandwidth for not resuming does not hurt all that much (not when mirroring complete DCC file bots anyhow).

Now if someone could reproduce DCC resume corruption with X-Chat on both sides that would probably be worth investigating.