A bug in DCC sends causing data loss, MIRC v6.12

OK i found this.

Bug appears in Mirc v6.12 (raw) on W2K, WXP & W98

If u have auto accept a file type and files set to resume.
And you are sent a file that is the same name, but shorter than the one you currently have, mirc requests a resume of the file from position zero, then apon the resumed file being sent, the file you had is deleted (well made zero bytes long)

User1 has BOB.TXT 50,000 bytes
User2 has BOB.TXT 1,000,000 bytes

User1 sends User2 BOB.TXT
User2 requests a resume from position zero
User1 accepts the resume request and resume sends the file from position zero(+1)

Debuglisting of User2 (with mirc v6.12 where the bug occurs)

<- :User1!~User1@Blah.com PRIVMSG User2 :DCC SEND BOB.TXT 414939748 1874 50000
-> sakura.tx.us.rizon.net PRIVMSG User1 :DCC RESUME "" 1874 0
<- :User1!~User1@Blah.com PRIVMSG User2 :DCC ACCEPT "BOB.TXT" 1874 0

The result is the loss of the file you had in the download folder and replacement with the new one being sent, This well could be a incomplete version of the one you already had.

This behavour doesnt occur in pre v6.12, in them a resume is requested from 991808 (8kb back from the end of the file), and no resume occurs as that is beyond the end of the senders file.

This bug can be corrected using this remote script.

Code:

 
CTCP ^*:DCC SEND *:?:Fix.Dcc.Send.Event $nick $1-
alias Fix.Dcc.Send.Event {
  ; # correct $1- to deal with files with spaces in #
  tokenize 62 $1 $+ &gt; $+ $2 $+ &gt; $+ $3 $+ &gt; $+ $nopath($filename) $+ &gt; $+ $gettok($1-,-3,32) $+ &gt; $+ $gettok($1-,-2,32) $+ &gt; $+ $gettok($1-,-1,32)
  ; # $1- = Nick Dcc Send Filename LongIP Port Filesize
  ;
  ; # Is there a file of greater or equal size already here #
  if ($file($getdir($4) $+ $4).size &gt;= $7) {
    ; # send a resume at 2gb so sender doesnt sit there waiting #
    msg $1 $chr(1) $+ DCC RESUME file.ext $6 2147483647 $+ $chr(1)
    ; # halt the dcc send being processed #
    halt
  }
}

So, I guess Khaled didn't answer your email?
I hope he's aware of this bug anyway..

(P.S.: reproduced here)

I wouldn't call this a bug in mIRC, but a fault in any auto-resume system being that there are too many scenerios to consider. You can however avoid this by grouping your downloads into subfolders by nickname... then you have less chance of receiving two different files of the same name from the same sender.

Presently, mIRC only has 4 options for its Auto-accept feature: Resume, Overwrite, Ask, Cancel. Perhaps Khaled could add more options like Rename, adding a (1) to the end of the file.
It could also default to Renaming if mIRC detects the resume file is a different filesize or from a different sender.. but then perhaps some people enjoy how it works today. *shrugs*

- Raccoon

I'd call this a bug. This is not a scenario to consider, since the file is *lost* at the end.. it's not just being re-written.

Also if you know a little about the person, this could be used maliciously to delete filed you know they have downloaded. Just create a much smaller version of what they just downloaded. Presuming they have auto accept, it could kill a file that took that all day to get.

I've never had anyone clobber a file by accident. A few have tried to do it on purpose and failed.

Just go to Options | DCC | Folders, then for each type go to Edit and then check "Sort files by nickname into own folders".

I would call it a bug, Mirc is not doing what it used to or what the help says its ment to. Resulting in files that can be deleted. The Option to use sepreate folders is all well and good, BUT isnt the solution to a "bug" in the dcc resume system.

I also well note becuase i didnt bother to in the first message, that the filename returned isnt FILE.EXT or the filename being sent (as its stated to do from 6.0? 6.1?) its just "" this also appears to cause some problems for non mirc clients sending files, but im assuming that these two things maybe connected, possably for some reason the sending filename isnt being passed to the resume routines correctly, thus the filename "" is checked and said to be zero bytes long, thus the resume is requested from zero. If that is the problem, then simply correcting the filename being passed to the resume routine, well eliminate the resume from zero problem.

version.txt:
from v6.1,

90.In the DCC Resume and Accept ctcp messages, mIRC now uses the original transfer filename instead of "file.ext".