System Administration
Showing results for 
Search instead for 
Did you mean: 

FTP Arguments too long error message.

Danny Fang
Frequent Advisor

FTP Arguments too long error message.


I attempted to FTP approx 2000 files with the filenames shown below. However, I obtained the error msg "Arguments too long error message." at the FTP prompt.

$ ls ./nortel-bss-v16-input-NetworkRails
danny@dimebag ~/nortel-bss-v16-input-NetworkRails $ ftp
Connected to 9.XXX.XX.XXX (9.XXX.XX.XXX).
220 9.XXX.XX.XXX FTP server ready.
Name (9.XXX.XX.XXX:danny): danny
504 AUTH SSL not supported.
SSL not available
331 Password required for danny.
230 User danny logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd /LOCAL/nortel-bss-v16/VS
250 CWD command successful.
ftp> prompt
Interactive mode off.
ftp> mput *.lif
Arguments too long

May I know how can I resolve this error ?

Is there a way that I could this with find? If so, I'd really appreciate it if anyone could show me how it's done.

Steven Schweda
Honored Contributor

Re: FTP Arguments too long error message.

That seems to be a _very_ lame FTP client.

If you have interactive access to the remote
system, it'd probably be easier to collect
all the files using "tar"+gzip (or bzip2) (or
Zip, or something), then use FTP to move the
single archive file, and finally unpack the
archive on the remote system. (Compressing
the data using gzip/bzip2 or Zip can save
time by making the FTP transfer faster, too,
if the CPUs are faster than the network.)

Does "man ftp" suggest any clever
alternatives to "mput *" (like getting a list
of files from a file)? Otherwise, I see a
relatively ugly shell script in your future.
Danny Fang
Frequent Advisor

Re: FTP Arguments too long error message.

HI Steven,

i fact, i had thought about bundling the entire list of files into a tar bundle and compressing them before transferring the single tar-bundle. However, the disk space posed an issue. That's the reason for me asking about transferring the multiple individual files.

Steven Schweda
Honored Contributor

Re: FTP Arguments too long error message.

> However, the disk space posed an issue.

An "issue"? Is that anything like a problem?

How big are the files? How compressible are
they? How much free disk space do you have?

I don't do much with Linux these days. There
could be a less stupid FTP client out there,
James R. Ferguson
Acclaimed Contributor

Re: FTP Arguments too long error message.

Hi Danny:

> mput *.lif
Arguments too long

This 'glob'bing (as it is called) has limitations. You can see the limit of the array that holds the expansion of all the names and their cumulative length with:

# getconf ARG_MAX

That said, you could break up the 'mput' into pieces like:

mput [a-f]*.lif
mput [g-n]*.lif

...etc. or you might use 'find' and pipe its output to an FTP shell script. As Steven suggested, too, and you agreed, using 'tar' to first bundle the files and then to FTP that bundled archive is always an option.



Jimmy Vance

Re: FTP Arguments too long error message.

Another method is to use netcat and tar to stream the files from one system to another across the network

move data from machine a to machine b

on machine a

# cd /path
# tar -cf - . | nc -w 10 -l -p 5432

on machine b

# cd /path
# nc -w 5 5432 | tar -xvf -

the command sets up a tar process on machine a that waits for a tcp connection on port 5432. When a client (machine b) connects, tar simply sends all the data through that tcp port. No temporary files are required. On machine b, another tar process reads from the network via netcat, writing the data to the disks as it streams over the network

Some distributions the command is nc, others it's netcat, if you have a firewall use an open port, netcat doesn't care what port number as long as it's the same on both ends

No support by private messages. Please ask the forum!      I work for HPE

If you feel this was helpful please click the KUDOS! thumb below!   
Steven Schweda
Honored Contributor

Re: FTP Arguments too long error message.

> on machine b

Of course, if you can log into machine b
using rsh or ssh, then you can do the work
without dragging netcat into the picture.

And, in any such pipeline, it could be wise
to throw in a gzip or bzip2 (at each end) to
trade CPU consumption for network