You can do it in a "CTCP ^*:DCC SEND *:{" event however just as Riamus2 said, thats on the recievers end, his end would just need to truncate X bytes of the end of the file, then the resume would start at that shorter file size minus 8192 bytes (the standard rollback).
I think the problem might be minimized by you by setting "/FSEND off" from memory this allows your end to send the next packet before the previous one is acknowledged, why this would cause corruption at the recievers end im not sure, it might be it allowes a missing packet to desync the files. ie you send packets [1][2][3][4][5][6] they recieved [1][2][3][5][6] becuase they missed [4] but you kept sending so they thought [5] was [4] etc.
Fast sends is also menually (is that a word?) switch off able in /DCC SEND (see fast send tick box).
If this is the problem then roll back being larger is unlikley to fix the problem, since its a missing packet which might be anywhere.
Rollback was designed to remove the last packet only as this maybe faulty during the connection breach, looks like it was hardcoded to the largest packet size at some time, this being 8kb
* there is one last problem with using a script also, i just remebered, lets assume you removed 1meg, everytime someone sent the MESSAGE they were going to send the file it would remove 1meg, older mircs also removed the 8kb this way, now they wait for the file to actually be sent.
I demonstrated this flaw to a freind once, by repeatedly sending him the im going to send you the file message, over and over untell i deleted the whole file. This has thankfully been fixed
