Autoaccepted DCC transfers fail; manually-accepted ones work.

[Adam Buchbinder]

Binary package hint: xchat-gnome

Open xchat-gnome. Go to Edit->Preferences->File Transfers & DCC. Make sure "Auto-accept DCC file transfers" is checked.

Attempt to start a file transfer. It *should* start, but go to IRC->File transfers and note that it's stuck on zero percent. The sending server will time out; it appears not to have received the accept message.

Note that if "Auto-accept DCC file transfers" is *not* checked, the transfer works properly. The problem has something to do with the autoaccept option. As a consequence, the user can't queue files and walk away; it's impossible to download files without time-sensitive user interaction, which significantly reduces the usefulness of the DCC client.

(The version I'm running is patched against bug 315243, which only changes the GUI layout. I've seen the bug on the unpatched version as well.)

I'll see about getting some network traces on this, as well as seeing if upstream still has the issue; I have my own XDCC bot running, which means I can see both sides of the equation.

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
Package: xchat-gnome 1:0.24.1-0ubuntu2~adb1
ProcEnviron:
 SHELL=/bin/bash
 PATH=/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
SourcePackage: xchat-gnome
Uname: Linux 2.6.27-7-generic i686
UnreportableReason: This is not a genuine Ubuntu package

[Adam Buchbinder (adam-buchbinder)]

Additionally, I can receive files from the same DCC bot using irssi, both manually and with dcc_autoget = on. (I set up a copy of iroffer on my local machine for testing purposes.) I used this to tentatively conclude that the problem is on xchat-gnome's end of things.

After toggling the autoreceive settings, it started to work, and I couldn't get it to fail again. I went back and deleted ~/.xchat2/xchat.conf, and the problem showed itself again. Attached find a diff between xchat.conf~ (the working version) and xchat.conf (the broken version).

The difference appears to be that xchat-gnome sets dcc_auto_send to 2 by default; when the setting is set manually, it's set to 1. ("dcc_auto_send" is a misnomer; it should be called "dcc_auto_receive".) However, when autoreceive is disabled, it's set to 0, not 2. To sum up:

dcc_auto_send = 0 -> Receive isn't autostarted; confirmation dialog pops up.
dcc_auto_send = 1 -> Receive is autostarted.
dcc_auto_send = 2 -> Receive isn't autostarted; confirmation dialog doesn't pop up.

I'm looking into the source now to see why this might be, and what the right fix is. I'm bearing in mind that we need to maintain compatibility with xchat--the options in xchat are "never autostart", "always autostart" and "browse for save folder for each file", so we'll likely have to seamlessly map the last one to "always autostart" in xchat-gnome.

[Adam Buchbinder (adam-buchbinder)]

xchat's default behavior is to set autodccsend (in the prefs file, that's auto_dcc_send) to 2, which is "browse mode".

dcc_auto_send = 0 -> ("No") File is added to the receive window in "waiting" state. (Can hit a button to start it.)
dcc_auto_send = 1 -> ("Yes") File is added to the receive window in "active" state, starts downloading.
dcc_auto_send = 2 -> ("Browse for save folder every time") File is added to the receive window in "waiting" state, save-as dialog pops up.

The default, in xchat-gnome's src/common/cfgfiles.c, is *also* to set it to 2. This is apparently inherited from xchat, which does the same, and this is the reason that new installs of xchat-gnome have broken DCC functionality. Several options present themselves for fixes:

* Extend xchat-gnome to have three possibilities for that pref: autoaccept, don't autoaccept, and pop up the save-as dialog. This might be implemented as two checkboxes, with the "autoaccept" one enabling/disabling the "ask for location" one.
* Force xchat-gnome to default to '0' ("ask"), as this is likely the safest behavior given the two options. If the imported preference is 2, force it to 0.
* Make xchat-gnome interpret 0 (don't autoaccept) in the same way as 2 (browse for save folder)--that is, if the user doesn't want to save the file, they can just hit "cancel". This still leaves the question of what to save this preference as--0 or 2?--from the preferences dialog.

I'm leaning toward the last option, but I suppose a change in behavior like this should be run by the upstream developers. As a stopgap, I think that we should at least default the preference to 0 ("ask"), and interpret dcc_auto_send == 2 the same way we currently do 0, for minimal disturbance of the user's existing preferences. I'll open an upstream bug if I can get the upstream SVN version to compile.

[Adam Buchbinder (adam-buchbinder)]

Pardon me; that should be "in the prefs file, that's dcc_auto_send".

The attached patch makes dcc_auto_send = 0 and dcc_auto_send = 2 have the same behavior, by replacing the check for "prefs.autodccchat == FALSE" with a check for "prefs.autodccchat != 1". It affects only src/fe-gnome/dcc-window.c.

I've tested the attached patch, and it seems to work for me. If anyone else would like to try it, I can upload the changes to my PPA.

[Sebastien Bacher (seb128)]

the bug has been fixed upstream now

[Sebastien Bacher (seb128)]

http://git.gnome.org/browse/xchat-gnome/commit/?id=3982672d0bfda9a6f8ad6b2109ddf03a3dd92688

[Bryce Harrington (bryce)]

Can someone verify if the version in natty carries this fix? If not, then this should be added to sponsors queue to get packaged and included in natty.

[Dave Walker (davewalker)]

The upstream fix is in the version currently in Natty. Marking Fix Released.