Thanks for your reply. I can understand reluctance to alter dcc. I'll make a related feature request post, which your reply made me think of, which hopefully falls far enough outside altering the dcc protocol.
As for the receiver, when I test this here, it tells me that a larger file exists than the one being sent to me and gives me the option to overwrite/cancel.
It looks like you're referring to the dialog the receiver gets when setting 'if file exists' to 'ask'. I'd forgotten to mention that I was describing how things are when /sreq is set to auto-get files and 'if file exists' is set to 'resume'. The 'ask' dialog doesn't always tell by filesize that the existing is larger than incoming. Though, you can infer the incoming is smaller by seeing that the 'resume' button is disabled. If the 2 sizes displayed are the same number, you don't know whether they're both exactly the same size, or if the incoming file is slightly larger but both files round to the same 1/10th kb size.
What I was trying to say is that when mIRC is set to auto-get and automatically resume incoming files, and someone sends a filename with size smaller than the receiver's existing file, the receiver sees the notice
-sender- DCC Send
versions.txt (sender's IP)
and the CTCP DCC SEND event gets triggered, but if the receiver doesn't have a script which intercepts the CTCP event, all they see is the above notice and then nothing happens.
When I mentioned no message about the invalid incoming DCC, I was thinking of how the sender gets a warning in the status window when the receiver requests a resume-get using the wrong port number or waits too long to accept the resume-get.
DCC Resume from sender rejected (invalid parameters)
During auto-get-auto-resume settings, by ignoring the incoming file once the receiver's mIRC discovers it's smaller than their own existing file, the receiving mIRC is treating the DCC SEND as if it contains an invalid size parameter, it's just not displaying a message to themselves like the sender sees when they see the receiver reply uses the wrong resume-port.
If the file exists and has content, mIRC should ask you if you want to resume it.
In most cases I agree, however when the filesize is 1-8192, mIRC's resume-get at offset zero is not resuming any content, it's wiping out the entire content and introduces RESUME into the situation where it doesn't benefit the receiver, and can inconvenience both sides when the sender's router is changing ports so the receiver's resume-get message responds with an invalid port number.
It seems it would be preferable for the receiving mIRC to always treat the 'if-file-exists' settings as if it's 'overwrite' if the incoming filesize is 1-8192, because that's the same effect as a resume-get at offset zero.
It's creating the same effect as 'overwrite' except it's introducing RESUME into the situation, which some people can't do because of something their ISP is doing. For years I had problems because U-Verse intermittently changed the port number between when my mIRC sends the file and the receiver gets the file. This allowed me to successfully DCC SEND except when the receiver asked for a resume-get, which failed because they saw the file coming in from a different port than it was actually sent from. When resuming at offset zero, nobody benefits from any preserved content, and it appears that mIRC doesn't delete my existing 1-byte file if the incoming overwrite fails to begin a connect because they're unable to dcc send.
This was implemented a long, long time ago due to the common occurrence of the last packet of a file being corrupted.
I wasn't aware that it was common for the file's last packet to be corrupted while still letting both sides think 100% of the file has transferred. It's common for jpg and zip files to be in the situation where a slightly smaller file in the download folder is resumed by an unrelated-but-larger file that happened to have the same filename. And, in the rare cases where I've downloaded a file that turned out corrupted, I can't remember a case where I found that the corruption was in the final packet. The corruption was either somewhere in the middle of the transfer, or was caused by the sender's file already being corrupted before the transfer. Maybe I've just been lucky.
Since people are now using packet sizes larger than 8kb, I was hoping that the lack of an epidemic of data corruptions while mIRC resumes only 8kb of a 64kb packet meant that replacing the final 8kb of resume-get files or resuming same-size files could be something people could tell their mIRC to opt out of, or if they do have problems, they could increase the portion of the file they wish to replace during the resume-get.