curl-library
OS/400 FTP Server Related Problem
Date: Sat, 21 May 2011 21:23:02 -0400
I've been trying to update some software that hasn't been patched in a
few years, and bring it up to date on a modern OS. This software
servers as a middleman to receive files, decrypt them, and send them
up to one of our OS400 systems. It uses command-line cURL to transfer
the files to the destination system. The current software has been
working for awhile on cURL 7.15.1.
In bringing it up to date, I've run into issues surrounding the patch
referenced in this thread from 2009 titled "OS400 ftp server related
problem":
http://curl.haxx.se/mail/lib-2009-08/0201.html
To summarize, this program attempts to identify an OS400 system and,
if detected, sends a NAMEFMT 1 command, which puts the system into a
hierarchical folder structure like most of us are used to on
linux/unix/windows systems (In OS400 parlance, this transfers files to
the IFS).
The problem is, my software actually needs it to be in NAMEFMT 0 most
of the time, and on the rare occasions when I need the IFS, there was
a simple command-line method to change modes.
That is, to transfer to the host 'os400.company.org' to the library
OPERATOR in the native FS, we'd use the command:
curl --upload-file <filename>
ftp://username:password@os400.company.org/OPERATOR/
If we wanted to upload to the IFS (a hierarchical filesystem), we'd
simply add an extra '/', which would change it automatically. i.e. if
we wanted to upload to /var/spool/transfers/, we'd run:
curl --upload-file <filename>
ftp://username:password@os400.company.org//var/spool/transfers/
The old behavior worked fine for us, but the new behavior assumes we
always want to transfer to the IFS. It would be nice if there was a
command-line switch to override this "Operating System Autodetection".
Naturally, I can edit the source to remove these commands from being
sent, but it would be nice if it were configurable so that I would
eventually be able to revert to my distro's patch mechanisms to
receive security updates. I'm not exactly clear on how this patch
fixed the OP's problem, since his complaint was that it defaulted to
NAMEFMT 1 if he reused a connection. I'm not reusing a connection,
but it is defaulting to NAMEFMT 1 no matter what now.
Thanks for your time,
Fred
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-05-22