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 a point-fix. The static buffers that limit the length of the command line are: char cmdline[128] in updown.c:updown() char buf[128] in updown.c:translate() char * words[128] in util.c:fastexec() Version-Release number of selected component (if applicable): minicom-2.00.0-12 How reproducible: Always Steps to Reproduce: 1.start minicom 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. Additional info: 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 operations. 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