mIRC Home    About    Download    Register    News    Help

Print Thread
#268664 07/04/21 11:27 PM
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
In rare cases, DCC GET receives a file which indicates complete, yet the file on disk is incomplete.

In the help channel I was helping someone who was getting an error message each time trying to receive a file, with the error saying broken pipe. The cause turned out to be that the getdir was on a disk that was full.

I tried to replicate it for myself by filling up a flash drive then setting my downloads folder pointing to it. I wasn't able to replicate the broken pipe message when receiving an incomplete file, but I was able to create a situation like what I've seen very rarely intermittent, but which I was not able to replicate nor reproduce on-demand, until now. With the disk being almost-full, the FILERCVD event triggers with $get(-1).rcvd being the full filesize, but the created disk file was smaller.

On this flashdrive, it behaves as if the cluster size is 32kb, where the free space changes by that much when adding a tiny file. If I received a file which was significantly larger than the free-space, it would fail with the normal 'incomplete' message without any mention of a broken pipe. However when the filesize was just a few kb larger than the free-space, the FILERCVD event triggers and shows the message as if the file is complete, even though it isn't.

With free space being 128kb = 131072, I receive a filesize 134385 and mIRC reports it received complete, however the disk file size is only 131022 and free space is now zero.

With free space being 64kb = 65536, I receive a filesize 66060 and mIRC reports it received complete, however the disk file size is only 65511 and free space is now zero.

With free space being 672kb = 688128, I receive a filesize 695698 and mIRC reports it received complete, however the disk file size is only 658030 and free space is now zero.

Occasionally, the behavior is the same as above, except the file doesn't get created at all, and free space isn't reduced.

Occasionally the get-file will report as incomplete to the receiver, but the sender sees the transfer as complete.

I'm guessing this technically is not a DCC problem, because technically the transfer is complete, it's just that the separate "save to disk" fails. But if there is a disk write error, there should be some kind of error message about that.

And just to be clear, the intermittent situations in the past where FILERCVD complete was incomplete on disk, they were not related to running out of disk space, this is just a way to trigger the rare behavior predictably.

maroon #268666 08/04/21 09:46 AM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. I have not been able to reproduce this issue here so far. Just to confirm: this is happening when the size of the file being downloaded is exactly one block/cluster size larger than the available disk space?

Khaled #268667 08/04/21 10:01 AM
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
When the file uses 1 more cluster than the free space, so it can be mere kb above freespace. And when a partial file is saved on disk, it's given a filesize that's a handful of bytes shorter than the original freespace.

if ((filesize - freespace) < cluster size) && (filesize > freespace) goto glitch

Last edited by maroon; 08/04/21 10:15 AM.
maroon #268668 08/04/21 02:18 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks this issue has been fixed for the next version.

maroon #268669 08/04/21 02:23 PM
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Originally Posted by maroon
I'm guessing this technically is not a DCC problem, because technically the transfer is complete, it's just that the separate "save to disk" fails.


I have nothing extra to add about the reported issue, but I would like to opine that file receiving is a combination of the DCC protocol completing correctly and the file being written to disk correctly - and either both succeed or the transfer was a failure.


Link Copied to Clipboard