Greetings!

For once, Google has failed me. We have a process that parses through a list of recently changed files, then assembles them as ftp commands in a shell script and executes the shell script. However, the file names have been getting longer and longer to the point where my command is over 200 characters long, resulting in errors such as: "sorry, input line too long" when issuing the put command (put /path/to/file/localfile /path/to/file/remotefile) Since these files are kept throughout various directories, I hate to issue a change directory command for every put option.

Is this an FTP issue? A Linux issue? A Windows issue? (The destination server is a Windows FTP server, but its logs don't even show an attempt to STOR the file).

My ftp client is ftp-0.17-17.2 (which is the most current one Red Hat offers) running RHEL 3.

Thanks in advance for your help.

--Ziggie

I've only seen these issues with Windows. What version of Windows? I know 2000 had a shorter line length limit than XP does. I don't think it lies within Linux or you're FTP client.

that error message comes from the ftp client. From netkit-ftp source code:

~/netkit-ftp-0.17$ grep -n "input line too long" ftp/main.c
327: printf("sorry, input line too long\n");

try another ftp client, perhaps, or if you're trying to synchronize files try something like rsync.

Actually you're right, checked the source from a RHEL SRC RPM for ftp, has same code and tested myself. You either need to find a new client and or cd into the directory to then transfer the file. I wouldn't mess with setting up an rsync server on a windows server.

my, aren't you guys full of good news.

any recommended RHEL compatible FTP command line clients that are ideal for batch processing?

and since I don't control the destination server, rsync is not an option (although, I wonder if there is a way to mount an FTP session as a local drive....LoL)

well, you're hitting a "corner-case" limit in the netkit ftp client, so other clients could have other arbitrary limits that won't be apparent until you run into them. with that caveat in mind, I'd try ncftpbatch.

And like mentioned before, Windows (depending on version) itself could also have a limitation of the input line as well as I've seen, so changing ftp clients might not resolve the actual problem.

not likely. a good ftp client (like the ncftp family of clients) will parse the user input into RFC compliant (read "legal") FTP commands, so the server won't know the difference between the batched vs. typed user input. And even on the server side, the FTP behavior is not a windows issue, it's an issue with the particular FTP server application being used.

I'm unsure if there is a specific limit on string length in the FTP protocol, however, so be aware of that too. You are generally at risk of failure at some point when using such long strings, since most software imposes limits on data lengths to prevent buffer overflow attacks and such (which is a good thing).

For what it's worth, lftp worked just fine for me. It was a simple modification to use it instead of the standard ftp client.

Thanks for all your help!!