GNU bug report logs -
#59135
Receiving large files with ERC-DCC
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59135 in the body.
You can then email your comments to 59135 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59135
; Package
emacs
.
(Tue, 08 Nov 2022 22:04:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Tohiko Looka <toh.looka <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Tue, 08 Nov 2022 22:04:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
When receiving large files with ERC-DCC I get the error
ERC-DCC (erc-pack-int): packet too large
incessantly which makes Emacs unresponsive until eventually the IRC
server connection is closed.
I believe this happens when the file size is larger than 2 or 4 GB
which does not fit in an integer. This causes a failure when the
function erc-dcc-get-filter tries to send back the number of received
bytes.
Is there a way around this?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59135
; Package
emacs
.
(Wed, 09 Nov 2022 14:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 59135 <at> debbugs.gnu.org (full text, mbox):
Hi Tohiko,
Tohiko Looka <toh.looka <at> gmail.com> writes:
> When receiving large files with ERC-DCC I get the error
>
> ERC-DCC (erc-pack-int): packet too large
What version of Emacs and ERC is this? If you have the command
`erc-bug', please consider using it to prepare ERC bug reports in the
future.
> incessantly which makes Emacs unresponsive until eventually the IRC
> server connection is closed.
That sounds like a bug. The process should probably be killed before the
error is signaled.
> I believe this happens when the file size is larger than 2 or 4 GB
> which does not fit in an integer.
Right. Desktops were mostly 32 bits back when DCC was a thing, and the
protocol reflects that.
> This causes a failure when the function erc-dcc-get-filter tries to
> send back the number of received bytes.
>
> Is there a way around this?
It depends on the file sender. If they're actually verifying your
reports, then you're out of luck because who's to say how reporting
should proceed on either side, post-overflow? IOW, if the reporter (file
receiver) wants to send 5- or 8-byte reports or wrap back around, that
needs to be coordinated beforehand with the other party (the file
sender).
Now, there *is* a variation of the protocol that ERC doesn't officially
support but that it has nevertheless partially implemented (a flavor of,
anyway). Check with the sender and see if they're operating in so-called
"turbo" mode (sometimes called TSEND). I've heard that some senders
enable it implicitly but don't announce that fact (if they're even aware
of having done so).
Regardless, if ERC thinks it's in a turbo-aware conversation, it won't
send reports at all. You can toggle this behavior with the -t switch
starting in Emacs 29.1. See the command usage in the ;;; Commentary
section in erc-dcc.el [1] and maybe some related variables further down
[2]. There's also bug#54458 [3], which gave rise to that feature. Hope
that helps.
Thanks,
J.P.
[1] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/erc/erc-dcc.el?id=1f29ee2d#n46
[2] https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/erc/erc-dcc.el?id=1f29ee2d#n979
[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54458
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59135
; Package
emacs
.
(Wed, 09 Nov 2022 17:18:03 GMT)
Full text and
rfc822 format available.
Message #11 received at 59135 <at> debbugs.gnu.org (full text, mbox):
Hi J.P.,
> What version of Emacs and ERC is this? If you have the command
> `erc-bug', please consider using it to prepare ERC bug reports in the
> future.
A sorry, I didn't realize erc had its own bug reporting mechanism.
I also should have included that I am using Emacs 28.1 the ERC 5.4.
> Regardless, if ERC thinks it's in a turbo-aware conversation, it won't
> send reports at all. You can toggle this behavior with the -t switch
> starting in Emacs 29.1. See the command usage in the ;;; Commentary
> section in erc-dcc.el [1] and maybe some related variables further down
> [2]. There's also bug#54458 [3], which gave rise to that feature. Hope
> that helps.
I will try this.Thanks
Reply sent
to
"J.P." <jp <at> neverwas.me>
:
You have taken responsibility.
(Mon, 22 May 2023 04:23:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Tohiko Looka <toh.looka <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 22 May 2023 04:23:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 59135-done <at> debbugs.gnu.org (full text, mbox):
Tohiko Looka <toh.looka <at> gmail.com> writes:
> Hi J.P.,
>
>> What version of Emacs and ERC is this? If you have the command
>> `erc-bug', please consider using it to prepare ERC bug reports in the
>> future.
> A sorry, I didn't realize erc had its own bug reporting mechanism.
> I also should have included that I am using Emacs 28.1 the ERC 5.4.
>
>> Regardless, if ERC thinks it's in a turbo-aware conversation, it won't
>> send reports at all. You can toggle this behavior with the -t switch
>> starting in Emacs 29.1. See the command usage in the ;;; Commentary
>> section in erc-dcc.el [1] and maybe some related variables further down
>> [2]. There's also bug#54458 [3], which gave rise to that feature. Hope
>> that helps.
>
> I will try this.Thanks
Closing this bug since there hasn't been any action in six months or so.
If the problem persists, please let me know, and I'll reopen it. Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 19 Jun 2023 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.