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.

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 #