Irssi core bugs

Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 85 Notice: Undefined index: tasklist_type in /var/www/bugs.irssi.org/includes/class.tpl.php(128) : eval()'d code on line 90
  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category core
  • Assigned To No-one
  • Operating System Linux
  • Severity High
  • Priority Normal
  • Reported Version Irssi 0.8.12
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 0
  • Private No
Attached to Project: Irssi core bugs
Opened by Gary D. Huffman, II (Arch4Ever) - 2008-04-06

FS#577 - DCC get accepts more than one xfer at a time with the same name, creating one big corrupt file

It seems the files are somehow streamed together? This could be a real annoyance for people using dcc_autoget.

This task does not depend on any other tasks.

Jilles Tjoelker (jilles)
Tuesday, 08 April 2008, 23:33 GMT
This may happen because the filesystem does not support hard links (e.g. FAT).
The documented behaviour would be overwriting each transfer with the next; but
to me it seems a bad idea for a DCC get to overwrite anything.

Try /set dcc_autorename on
Gary D. Huffman, II (Arch4Ever)
Wednesday, 09 April 2008, 04:00 GMT
FWIW, the test system is using ext2/3 only.
Gary D. Huffman, II (Arch4Ever)
Saturday, 12 April 2008, 14:48 GMT
FWIW, the test system is using ext2/3 only.
Gary D. Huffman, II (Arch4Ever)
Saturday, 12 April 2008, 14:50 GMT
Oops, sorry for the dupe comment (hit refresh and didn't realize it would resubmit the form).
Gary D. Huffman, II (Arch4Ever)
Saturday, 12 April 2008, 14:54 GMT
It occurs to me this is probably caused by dcc_autoresume being on. Could you not add a check to see if that file is already being resumed to keep it from corrupting the file?
Wouter Coekaerts (coekie)
Sunday, 29 March 2009, 09:39 GMT
I can indeed reproduce having multiple dcc resumes on the same file at the same time. But for me the end result is always ok; no file corruption (md5sums match). Tested on ext3 filesystem on Linux.
Wouter Coekaerts (coekie)
Sunday, 29 March 2009, 10:22 GMT
Just to be clear: I tested with sending the same file twice.
If you are receiving a *different* file twice with the same name, it'll be corrupted even if they aren't running at the same time, if you've got autoresume on.
Gary D. Huffman, II (Arch4Ever)
Thursday, 02 April 2009, 16:01 GMT
I am unable to reproduce the 'one big corrupt file' aspect with the same file being received/resumed from 2 different sources running the latest Arch Linux testing. It seems the corruption I experienced was due to one of the sources having a differing file.

It does seem to be a bad idea in general to allow this though. When dealing with larger files in this situation there would be significant bandwidth wasted.

It might be cool to turn this into a feature however. Since most people sending files usually aren't able to fill the pipe of the receiver, we could utilize the resume capabilities to get half the file from the first source and half of the file from the second source, etc, greatly reducing wait time. ;)

Loading...