Red Hat Bugzilla – Bug 98654
minicom limits how many files can be sent via zmodem
Last modified: 2007-04-18 12:55:30 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
Description of problem:
minicom limits the number of files that it can send using zmodem, even though it
allows you to select an arbitrary number of files.
The problem is that it writes the zmodem command line into static buffer of 128
bytes. Unfortunately, there are many static buffers, so it's not possible to do
The static buffers that limit the length of the command line are:
char cmdline in updown.c:updown()
char buf in updown.c:translate()
char * words in util.c:fastexec()
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.CTRL+A - S to send files
3.Tag 100 files with long names
4.Send the files.
Actual Results: Somewhere at the 128th character, the filename will be cropped.
The cropped filename will be sent (because it probably won't exist). The rest
of the files will be dropped.
Expected Results: All files should be sent, barring error within sz or rz.
I will submit a patch shortly.
Created attachment 92769 [details]
A patch to add dynamicly-sized command-line buffers to updown.c
This is a fix for the static buffers in updown.c. Note that, because fastexec
does not return under nomral circumstances, this patch introduces a memory
leak. This is not possible to fix without changing the way fastexec behaves.
Also, I only tested these changes for the operations that I was doing (sending
using zmodem). It's possible that it introduces regressions for other
The patch uses the assert() and I don't know if the Makefile defines -NDEBUG
for retail builds.
patch looks pretty good. adding a -DNDEBUG to the build process to cancel out
the assert() macros.
included in release 14