From d41c65d27e85cbaeaa11256c244f912e4dc7532d Mon Sep 17 00:00:00 2001 From: Andrew Pamment Date: Sun, 27 May 2018 09:39:05 +1000 Subject: [PATCH] Add ftplib to deps --- deps/ftplib-4.0-1/CHANGES | 191 + deps/ftplib-4.0-1/LICENSE | 171 + deps/ftplib-4.0-1/README.ftplib-4.0-1 | 18 + deps/ftplib-4.0-1/README.qftp | 41 + deps/ftplib-4.0-1/RFC959.txt | 3933 ++++++++++++++++++ deps/ftplib-4.0-1/additional_rfcs | 2 + deps/ftplib-4.0-1/html/FtpAccess.html | 42 + deps/ftplib-4.0-1/html/FtpCDUp.html | 26 + deps/ftplib-4.0-1/html/FtpChdir.html | 28 + deps/ftplib-4.0-1/html/FtpClearCallback.html | 27 + deps/ftplib-4.0-1/html/FtpClose.html | 32 + deps/ftplib-4.0-1/html/FtpConnect.html | 35 + deps/ftplib-4.0-1/html/FtpDelete.html | 28 + deps/ftplib-4.0-1/html/FtpDir.html | 37 + deps/ftplib-4.0-1/html/FtpGet.html | 34 + deps/ftplib-4.0-1/html/FtpInit.html | 22 + deps/ftplib-4.0-1/html/FtpLastResponse.html | 31 + deps/ftplib-4.0-1/html/FtpLogin.html | 30 + deps/ftplib-4.0-1/html/FtpMkdir.html | 28 + deps/ftplib-4.0-1/html/FtpModDate.html | 36 + deps/ftplib-4.0-1/html/FtpNlst.html | 33 + deps/ftplib-4.0-1/html/FtpOptions.html | 63 + deps/ftplib-4.0-1/html/FtpPut.html | 34 + deps/ftplib-4.0-1/html/FtpPwd.html | 30 + deps/ftplib-4.0-1/html/FtpQuit.html | 28 + deps/ftplib-4.0-1/html/FtpRead.html | 34 + deps/ftplib-4.0-1/html/FtpRename.html | 30 + deps/ftplib-4.0-1/html/FtpRmdir.html | 28 + deps/ftplib-4.0-1/html/FtpSetCallback.html | 78 + deps/ftplib-4.0-1/html/FtpSite.html | 28 + deps/ftplib-4.0-1/html/FtpSize.html | 38 + deps/ftplib-4.0-1/html/FtpSizeLong.html | 40 + deps/ftplib-4.0-1/html/FtpSysType.html | 31 + deps/ftplib-4.0-1/html/FtpWrite.html | 33 + deps/ftplib-4.0-1/html/doc.css | 29 + deps/ftplib-4.0-1/html/ftplib.html | 92 + deps/ftplib-4.0-1/html/index.html | 39 + deps/ftplib-4.0-1/html/qftp.html | 114 + deps/ftplib-4.0-1/src/Makefile | 73 + deps/ftplib-4.0-1/src/README | 24 + deps/ftplib-4.0-1/src/descrip.mms | 40 + deps/ftplib-4.0-1/src/ftplib.c | 1455 +++++++ deps/ftplib-4.0-1/src/ftplib.h | 120 + deps/ftplib-4.0-1/src/ftplib.opt | 8 + deps/ftplib-4.0-1/src/ftplib_alpha.opt | 35 + deps/ftplib-4.0-1/src/ftplib_ia64.opt | 35 + deps/ftplib-4.0-1/src/ftplib_vector.mar | 36 + deps/ftplib-4.0-1/src/qftp.c | 470 +++ deps/ftplib-4.0-1/src/qftp.opt | 2 + deps/ftplib-4.0-1/src/qftp_alpha.opt | 2 + deps/ftplib-4.0-1/src/qftp_ia64.opt | 2 + 51 files changed, 7896 insertions(+) create mode 100644 deps/ftplib-4.0-1/CHANGES create mode 100644 deps/ftplib-4.0-1/LICENSE create mode 100644 deps/ftplib-4.0-1/README.ftplib-4.0-1 create mode 100644 deps/ftplib-4.0-1/README.qftp create mode 100644 deps/ftplib-4.0-1/RFC959.txt create mode 100644 deps/ftplib-4.0-1/additional_rfcs create mode 100644 deps/ftplib-4.0-1/html/FtpAccess.html create mode 100644 deps/ftplib-4.0-1/html/FtpCDUp.html create mode 100644 deps/ftplib-4.0-1/html/FtpChdir.html create mode 100644 deps/ftplib-4.0-1/html/FtpClearCallback.html create mode 100644 deps/ftplib-4.0-1/html/FtpClose.html create mode 100644 deps/ftplib-4.0-1/html/FtpConnect.html create mode 100644 deps/ftplib-4.0-1/html/FtpDelete.html create mode 100644 deps/ftplib-4.0-1/html/FtpDir.html create mode 100644 deps/ftplib-4.0-1/html/FtpGet.html create mode 100644 deps/ftplib-4.0-1/html/FtpInit.html create mode 100644 deps/ftplib-4.0-1/html/FtpLastResponse.html create mode 100644 deps/ftplib-4.0-1/html/FtpLogin.html create mode 100644 deps/ftplib-4.0-1/html/FtpMkdir.html create mode 100644 deps/ftplib-4.0-1/html/FtpModDate.html create mode 100644 deps/ftplib-4.0-1/html/FtpNlst.html create mode 100644 deps/ftplib-4.0-1/html/FtpOptions.html create mode 100644 deps/ftplib-4.0-1/html/FtpPut.html create mode 100644 deps/ftplib-4.0-1/html/FtpPwd.html create mode 100644 deps/ftplib-4.0-1/html/FtpQuit.html create mode 100644 deps/ftplib-4.0-1/html/FtpRead.html create mode 100644 deps/ftplib-4.0-1/html/FtpRename.html create mode 100644 deps/ftplib-4.0-1/html/FtpRmdir.html create mode 100644 deps/ftplib-4.0-1/html/FtpSetCallback.html create mode 100644 deps/ftplib-4.0-1/html/FtpSite.html create mode 100644 deps/ftplib-4.0-1/html/FtpSize.html create mode 100644 deps/ftplib-4.0-1/html/FtpSizeLong.html create mode 100644 deps/ftplib-4.0-1/html/FtpSysType.html create mode 100644 deps/ftplib-4.0-1/html/FtpWrite.html create mode 100644 deps/ftplib-4.0-1/html/doc.css create mode 100644 deps/ftplib-4.0-1/html/ftplib.html create mode 100644 deps/ftplib-4.0-1/html/index.html create mode 100644 deps/ftplib-4.0-1/html/qftp.html create mode 100644 deps/ftplib-4.0-1/src/Makefile create mode 100644 deps/ftplib-4.0-1/src/README create mode 100644 deps/ftplib-4.0-1/src/descrip.mms create mode 100644 deps/ftplib-4.0-1/src/ftplib.c create mode 100644 deps/ftplib-4.0-1/src/ftplib.h create mode 100644 deps/ftplib-4.0-1/src/ftplib.opt create mode 100644 deps/ftplib-4.0-1/src/ftplib_alpha.opt create mode 100644 deps/ftplib-4.0-1/src/ftplib_ia64.opt create mode 100644 deps/ftplib-4.0-1/src/ftplib_vector.mar create mode 100644 deps/ftplib-4.0-1/src/qftp.c create mode 100644 deps/ftplib-4.0-1/src/qftp.opt create mode 100644 deps/ftplib-4.0-1/src/qftp_alpha.opt create mode 100644 deps/ftplib-4.0-1/src/qftp_ia64.opt diff --git a/deps/ftplib-4.0-1/CHANGES b/deps/ftplib-4.0-1/CHANGES new file mode 100644 index 0000000..1cd99eb --- /dev/null +++ b/deps/ftplib-4.0-1/CHANGES @@ -0,0 +1,191 @@ +The obligatory revision history... + +Changes from V4.0 to V4.0-1 + +1) Fix erroneous removal of local file on PUT when transfer fails. It +was an attempt to remove the local file on retrieve failure but the +the code was checking for the wrong value. + +2) Link data netbuf to control netbuf in FtpOpenPort instead of +routine that calls it. + +3) Fix check of response type in FtpClose. + +4) Add NULL check from nodename lookup. + +Changes from V3.1-1 to V4.0 + +1) License changed from GPL/LGPL to Artistic License 2.0. + +2) Many bugs reported over the years have been addressed. + +3) The reentrant versions of gethostbyname and getservbyname are used +if available. + +4) Internal buffers are larger which should allow for longer +filenames. + +5) The library will not output anything to stdout or stderr unless +ftplib_debug is defined. + +6) Some additional arguments are declared const. + +7) The second argument to FtpSize is the address of an integer to +receive the size of the remote file. The type of this argument has +been changed from int to unsigned int. A new function, FtpSizeLong, +returns the remote file's size as an unsigned long long. + +8) The second argument to the callback function has been changed from +an int to an unsigned long long. This value contains the number of +bytes transferred so far. + +9) The library version 1 interface compatability macros have been +removed from the header file. If your application needs them, extract +them from the old header file. + +10) The usage information in qftp.c has been corrected. + +11) qftp now accepts a '-s ' option to send as a SITE +command. + +12) qftp progress reports now use floating point calculation so that +large numbers don't cause overflows. If the remote server does not +support the SIZE command, qftp will update every 32KB. + +13) A new type-safe method is provided to establish a callback +function. Put the details of when the function should be called into +a FtpCallbackOptions structure and pass it to FtpSetCallback(). To +remove a callback, call FtpClearCallback(). + +14) Updated html documentation. + +Changes from V3.1 to V3.1-1 + +1) Delay setting the control handle pointer in the data handle until +after the transfer request has received a positive acknowledgement. +This should resolve problems calling FtpClose() on the data handle +when the transfer is rejected. + +2) Fix error handling in FtpRead() and FtpWrite(). + +3) Return status of transfer from FtpXfer() instead of status of +FtpClose(). + +4) Allow FtpClose() to be called on a control handle. This should be +used instead of FtpQuit() in cases where a transfer was interrupted. +FtpQuit() would attempt to send a 'QUIT' command and wait for a +response but this would be out of sync after an interrupt. + +5) The idle callback routine was not being set in the data handle if +the user didn't set FTPLIB_IDLETIME. Fixed this so it would get set +up if either this or FTPLIB_CALLBACKBYTES was set. + +6) Open local files in binary mode when appropriate. This is +necessary on some systems like NT and VMS. + +7) Added a wildcard mode to qftp for wildcard retrieves. Argument +after '-w' is treated as a remote wildcard file specification. + +Changes from 12/2/97 (V3) to .... (V3.1) + +1) Added FtpPwd(), FtpSysType(), FtpCDUp(), FtpSize() and FtpModDate(). + +2) Fixed bug in FtpClose() - It wasn't waiting for the '226 Transfer +Complete' since it didn't have access to the control connection. A +pointer to it is now kept in the data connection. + +3) Fixed bug in FtpClose() - The data connection wasn't being freed. This +could have resulted in memory leaks. + +4) Allow runtime selection of connection mode (PORT/PASV) with default set +at compile time. + +5) Added support for a user callback routine which can get called after a +user specified number of bytes are transferred or after waiting for data +on a socket for a user specified time period. + +6) Add FtpOptions() which allows changing connection options. Options +include connection mode, callback routine, and parameters regarding when +the user's callback routine gets called. + +7) Added checks to make sure strcpy()/sprintf()/etc. wouldn't write past +end of buffers. + +8) Modified build procedure to create a shared library. + +9) Added install option to makefile which installs under /usr/local. + +10) Modified qftp to use new interface. + +11) Modified qftp to log progress every 10% of file or every time data +is delayd by 1 second if -v setting is not zero. + +12) Modified qftp to use fgets() instead of gets(). + +------------------------------------------------------------------------ + +Changes from 3/15/97 to 12/2/97 + +1) FtpLastResponse() returns NULL if passed a NULL pointer. + +2) Added 'const' keyword on appropriate function arguments. + +3) First attempt to translate passed host string as an IP address in dot + notation by passing it to inet_addr(). If this fails, pass the string + to gethostbyname(). Apparently, some versions of gethostbyname() will + parse the translation of a dot notation address for you. One user + reports he knows of at least one that does not. In any case, it's the + right thing to do. + +4) Added protection from double inclusion to header file. Also added + 'extern "C"' for C++. + +5) Made sure qftp was passed two arguments before examining the second + one. + +6) Made sure all commands to the server were in upper case. I've been + told that some servers require this. + +7) Attempt to handle login to accounts with no passwords. + +8) Added common data transfer routines so that ascii mode transfers would + be handled properly in all cases. Also, exposed these routines for + user programs to call. There's now FtpAccess() to open a remote file + or directory, FtpRead() and FtpWrite() to pass data, and FtpClose() to + terminate the data connection. + +9) Added 'list' command to qftp to perform a terse directory (names + only). This could be piped into another copy of qftp to retrieve the + files. + +10) ftplib.c and ftplib.h are now covered by the LGPL instead of the GPL. + Feel free to send me a complementary copy of anything you develop + commercially with my libraries. All other programs are still covered + by the GPL. + +11) Added ability to specify a different port number than the default by + appending a colon and the desired port number to the remote host name + (e.g., remote.host.name:500 would connect to port remote.host.name on + port 500). + +------------------------------------------------------------------------ + +Changes from 8/31/96 version to 3/15/97 version + +1) Added copyright information to sources. + +2) Changed from 'port' to 'pasv' which I'm told will allow the routines + to work from behind a firewall. It's also a lot simpler and cleaner + than all that code to setup and accept a connect from the server. + +3) Added delete (ftprm) support to qftp.c. + +4) Modified qftp to allow use without a softlink by passing the ftp + command as the first argument. + +5) Added netbuf argument to all calls to eliminate static storage and + allow multiple simultaneous connections. + +6) Renamed routines from ftp*() to Ftp*() to avoid problems with existing + programs. Added macros in libftp.h to support old interface. Renamed + ftpOpen() to FtpConnect(). diff --git a/deps/ftplib-4.0-1/LICENSE b/deps/ftplib-4.0-1/LICENSE new file mode 100644 index 0000000..1a630a2 --- /dev/null +++ b/deps/ftplib-4.0-1/LICENSE @@ -0,0 +1,171 @@ +Artistic License 2.0 + +Copyright (c) 2000-2006, The Perl Foundation. + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. Preamble + +This license establishes the terms under which a given free software +Package may be copied, modified, distributed, and/or +redistributed. The intent is that the Copyright Holder maintains some +artistic control over the development of that Package while still +keeping the Package available as open source and free software. + +You are always permitted to make arrangements wholly outside of this +license directly with the Copyright Holder of a given Package. If the +terms of this license do not permit the full use that you propose to +make of the Package, you should contact the Copyright Holder and seek +a different licensing arrangement. Definitions + +"Copyright Holder" means the individual(s) or organization(s) named in +the copyright notice for the entire Package. + +"Contributor" means any party that has contributed code or other +material to the Package, in accordance with the Copyright Holder's +procedures. + +"You" and "your" means any person who would like to copy, distribute, +or modify the Package. + +"Package" means the collection of files distributed by the Copyright +Holder, and derivatives of that collection and/or of those files. A +given Package may consist of either the Standard Version, or a +Modified Version. + +"Distribute" means providing a copy of the Package or making it +accessible to anyone else, or in the case of a company or +organization, to others outside of your company or organization. + +"Distributor Fee" means any fee that you charge for Distributing this +Package or providing support for this Package to another party. It +does not mean licensing fees. + +"Standard Version" refers to the Package if it has not been modified, +or has been modified only in ways explicitly requested by the +Copyright Holder. + +"Modified Version" means the Package, if it has been changed, and such +changes were not explicitly requested by the Copyright Holder. + +"Original License" means this Artistic License as Distributed with the +Standard Version of the Package, in its current version or as it may +be modified by The Perl Foundation in the future. + +"Source" form means the source code, documentation source, and +configuration files for the Package. + +"Compiled" form means the compiled bytecode, object code, binary, or +any other form resulting from mechanical transformation or translation +of the Source form. Permission for Use and Modification Without +Distribution + +(1) You are permitted to use the Standard Version and create and use +Modified Versions for any purpose without restriction, provided that +you do not Distribute the Modified Version. Permissions for +Redistribution of the Standard Version + +(2) You may Distribute verbatim copies of the Source form of the +Standard Version of this Package in any medium without restriction, +either gratis or for a Distributor Fee, provided that you duplicate +all of the original copyright notices and associated disclaimers. At +your discretion, such verbatim copies may or may not include a +Compiled form of the Package. + +(3) You may apply any bug fixes, portability changes, and other +modifications made available from the Copyright Holder. The resulting +Package will still be considered the Standard Version, and as such +will be subject to the Original License. Distribution of Modified +Versions of the Package as Source + +(4) You may Distribute your Modified Version as Source (either gratis +or for a Distributor Fee, and with or without a Compiled form of the +Modified Version) provided that you clearly document how it differs +from the Standard Version, including, but not limited to, documenting +any non-standard features, executables, or modules, and provided that +you do at least ONE of the following: + +(a) make the Modified Version available to the Copyright Holder of the +Standard Version, under the Original License, so that the Copyright +Holder may include your modifications in the Standard Version. (b) +ensure that installation of your Modified Version does not prevent the +user installing or running the Standard Version. In addition, the +Modified Version must bear a name that is different from the name of +the Standard Version. (c) allow anyone who receives a copy of the +Modified Version to make the Source form of the Modified Version +available to others under (i) the Original License or (ii) a license +that permits the licensee to freely copy, modify and redistribute the +Modified Version using the same licensing terms that apply to the copy +that the licensee received, and requires that the Source form of the +Modified Version, and of any works derived from it, be made freely +available in that license fees are prohibited but Distributor Fees are +allowed. Distribution of Compiled Forms of the Standard Version or +Modified Versions without the Source + +(5) You may Distribute Compiled forms of the Standard Version without +the Source, provided that you include complete instructions on how to +get the Source of the Standard Version. Such instructions must be +valid at the time of your distribution. If these instructions, at any +time while you are carrying out such distribution, become invalid, you +must provide new instructions on demand or cease further +distribution. If you provide valid instructions or cease distribution +within thirty days after you become aware that the instructions are +invalid, then you do not forfeit any of your rights under this +license. + +(6) You may Distribute a Modified Version in Compiled form without the +Source, provided that you comply with Section 4 with respect to the +Source of the Modified Version. Aggregating or Linking the Package + +(7) You may aggregate the Package (either the Standard Version or +Modified Version) with other packages and Distribute the resulting +aggregation provided that you do not charge a licensing fee for the +Package. Distributor Fees are permitted, and licensing fees for other +components in the aggregation are permitted. The terms of this license +apply to the use and Distribution of the Standard or Modified Versions +as included in the aggregation. + +(8) You are permitted to link Modified and Standard Versions with +other works, to embed the Package in a larger work of your own, or to +build stand-alone binary or bytecode versions of applications that +include the Package, and Distribute the result without restriction, +provided the result does not expose a direct interface to the Package. +Items That are Not Considered Part of a Modified Version + +(9) Works (including, but not limited to, modules and scripts) that +merely extend or make use of the Package, do not, by themselves, cause +the Package to be a Modified Version. In addition, such works are not +considered parts of the Package itself, and are not subject to the +terms of this license. General Provisions + +(10) Any use, modification, and distribution of the Standard or +Modified Versions is governed by this Artistic License. By using, +modifying or distributing the Package, you accept this license. Do not +use, modify, or distribute the Package, if you do not accept this +license. + +(11) If your Modified Version has been derived from a Modified Version +made by someone other than you, you are nevertheless required to +ensure that your Modified Version complies with the requirements of +this license. + +(12) This license does not grant you the right to use any trademark, +service mark, tradename, or logo of the Copyright Holder. + +(13) This license includes the non-exclusive, worldwide, +free-of-charge patent license to make, have made, use, offer to sell, +sell, import and otherwise transfer the Package with respect to any +patent claims licensable by the Copyright Holder that are necessarily +infringed by the Package. If you institute patent litigation +(including a cross-claim or counterclaim) against any party alleging +that the Package constitutes direct or contributory patent +infringement, then this Artistic License to you shall terminate on the +date that such litigation is filed. + +(14) Disclaimer of Warranty: THE PACKAGE IS PROVIDED BY THE COPYRIGHT +HOLDER AND CONTRIBUTORS "AS IS' AND WITHOUT ANY EXPRESS OR IMPLIED +WARRANTIES. THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A +PARTICULAR PURPOSE, OR NON-INFRINGEMENT ARE DISCLAIMED TO THE EXTENT +PERMITTED BY YOUR LOCAL LAW. UNLESS REQUIRED BY LAW, NO COPYRIGHT +HOLDER OR CONTRIBUTOR WILL BE LIABLE FOR ANY DIRECT, INDIRECT, +INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING IN ANY WAY OUT OF THE USE +OF THE PACKAGE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/deps/ftplib-4.0-1/README.ftplib-4.0-1 b/deps/ftplib-4.0-1/README.ftplib-4.0-1 new file mode 100644 index 0000000..519c2a4 --- /dev/null +++ b/deps/ftplib-4.0-1/README.ftplib-4.0-1 @@ -0,0 +1,18 @@ +FTP Library Routines Release 4.0 +Thomas Pfau (tfpfau@gmail.com) +March 9, 2016 + +This package implements a callable interface to FTP. The FTP protocol is +specified in RFC 959. The library has been tested on linux, OpenVMS and +Windows NT. It should also work without major modification on other +POSIX systems. + +All programs using the library should include ftplib.h. + +The routines look at the global variable ftplib_debug to determine how +much information they should display. Level 1 has been left for user +programs. Level 2 displays all responses received from the server. +Level 3 displays all commands sent to the server. + +Function documentation is provided in HTML format in the html +subdirectory. diff --git a/deps/ftplib-4.0-1/README.qftp b/deps/ftplib-4.0-1/README.qftp new file mode 100644 index 0000000..804936a --- /dev/null +++ b/deps/ftplib-4.0-1/README.qftp @@ -0,0 +1,41 @@ +qftp is a simple program which demonstrates the use of ftplib. + +qftp performs directories or file transfers using the ftp protocol based +on the command it was invoked with and command line arguments. qftp +can be invoked through a softlink which indicates which operation it +should perform. + +To install, copy qftp to a directory in your path. Execute the following +commands in that directory: + + ln -s qftp ftpdir + ln -s qftp ftpget + ln -s qftp ftpsend + ln -s qftp ftprm + ln -s qftp ftplist + +Then, invoke qftp by using the commands ftpdir, ftpget, ftpsend, ftprm or +ftplist. + +qftp processes the command line in order. The first argument should be +the name of the system you wish to converse with. If you need to specify +login information, that should be specified next with '-l' and '-p'. On +UNIX systems, if you specify a username with '-l' and don't specify a +password with '-p', qftp will prompt for a password. It is a good idea +to do it this way as it keeps the password off the command line and out +of 'ps' and other displays. + +When working through a proxy firewall, specify the firewall machine's +name as the host. Specify the real host's name with the -l and -p +parameters. For example: + + ftpget firewall -l anonymous@real.host.com -p user@myhost.org + +The exit status from qftp can be used to determine whether the transfer +worked or not. Exit status 2 means a command line syntax error. 3 +indicates a failure while attempting to translate the system name into an +IP address. 4 indicates a failure attempting to connect to the remote +machine. 5 indicates a login failure. 6 indicates a remote command +error. 7 indicates a system call error. + +See the HTML documentation in the html subdirectory for more details. diff --git a/deps/ftplib-4.0-1/RFC959.txt b/deps/ftplib-4.0-1/RFC959.txt new file mode 100644 index 0000000..5c9f11a --- /dev/null +++ b/deps/ftplib-4.0-1/RFC959.txt @@ -0,0 +1,3933 @@ + + +Network Working Group J. Postel +Request for Comments: 959 J. Reynolds + ISI +Obsoletes RFC: 765 (IEN 149) October 1985 + + FILE TRANSFER PROTOCOL (FTP) + + +Status of this Memo + + This memo is the official specification of the File Transfer + Protocol (FTP). Distribution of this memo is unlimited. + + The following new optional commands are included in this edition of + the specification: + + CDUP (Change to Parent Directory), SMNT (Structure Mount), STOU + (Store Unique), RMD (Remove Directory), MKD (Make Directory), PWD + (Print Directory), and SYST (System). + + Note that this specification is compatible with the previous edition. + +1. INTRODUCTION + + The objectives of FTP are 1) to promote sharing of files (computer + programs and/or data), 2) to encourage indirect or implicit (via + programs) use of remote computers, 3) to shield a user from + variations in file storage systems among hosts, and 4) to transfer + data reliably and efficiently. FTP, though usable directly by a user + at a terminal, is designed mainly for use by programs. + + The attempt in this specification is to satisfy the diverse needs of + users of maxi-hosts, mini-hosts, personal workstations, and TACs, + with a simple, and easily implemented protocol design. + + This paper assumes knowledge of the Transmission Control Protocol + (TCP) [2] and the Telnet Protocol [3]. These documents are contained + in the ARPA-Internet protocol handbook [1]. + +2. OVERVIEW + + In this section, the history, the terminology, and the FTP model are + discussed. The terms defined in this section are only those that + have special significance in FTP. Some of the terminology is very + specific to the FTP model; some readers may wish to turn to the + section on the FTP model while reviewing the terminology. + + + + + + + +Postel & Reynolds [Page 1] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 2.1. HISTORY + + FTP has had a long evolution over the years. Appendix III is a + chronological compilation of Request for Comments documents + relating to FTP. These include the first proposed file transfer + mechanisms in 1971 that were developed for implementation on hosts + at M.I.T. (RFC 114), plus comments and discussion in RFC 141. + + RFC 172 provided a user-level oriented protocol for file transfer + between host computers (including terminal IMPs). A revision of + this as RFC 265, restated FTP for additional review, while RFC 281 + suggested further changes. The use of a "Set Data Type" + transaction was proposed in RFC 294 in January 1982. + + RFC 354 obsoleted RFCs 264 and 265. The File Transfer Protocol + was now defined as a protocol for file transfer between HOSTs on + the ARPANET, with the primary function of FTP defined as + transfering files efficiently and reliably among hosts and + allowing the convenient use of remote file storage capabilities. + RFC 385 further commented on errors, emphasis points, and + additions to the protocol, while RFC 414 provided a status report + on the working server and user FTPs. RFC 430, issued in 1973, + (among other RFCs too numerous to mention) presented further + comments on FTP. Finally, an "official" FTP document was + published as RFC 454. + + By July 1973, considerable changes from the last versions of FTP + were made, but the general structure remained the same. RFC 542 + was published as a new "official" specification to reflect these + changes. However, many implementations based on the older + specification were not updated. + + In 1974, RFCs 607 and 614 continued comments on FTP. RFC 624 + proposed further design changes and minor modifications. In 1975, + RFC 686 entitled, "Leaving Well Enough Alone", discussed the + differences between all of the early and later versions of FTP. + RFC 691 presented a minor revision of RFC 686, regarding the + subject of print files. + + Motivated by the transition from the NCP to the TCP as the + underlying protocol, a phoenix was born out of all of the above + efforts in RFC 765 as the specification of FTP for use on TCP. + + This current edition of the FTP specification is intended to + correct some minor documentation errors, to improve the + explanation of some protocol features, and to add some new + optional commands. + + +Postel & Reynolds [Page 2] + + + +RFC 959 October 1985 +File Transfer Protocol + + + In particular, the following new optional commands are included in + this edition of the specification: + + CDUP - Change to Parent Directory + + SMNT - Structure Mount + + STOU - Store Unique + + RMD - Remove Directory + + MKD - Make Directory + + PWD - Print Directory + + SYST - System + + This specification is compatible with the previous edition. A + program implemented in conformance to the previous specification + should automatically be in conformance to this specification. + + 2.2. TERMINOLOGY + + ASCII + + The ASCII character set is as defined in the ARPA-Internet + Protocol Handbook. In FTP, ASCII characters are defined to be + the lower half of an eight-bit code set (i.e., the most + significant bit is zero). + + access controls + + Access controls define users' access privileges to the use of a + system, and to the files in that system. Access controls are + necessary to prevent unauthorized or accidental use of files. + It is the prerogative of a server-FTP process to invoke access + controls. + + byte size + + There are two byte sizes of interest in FTP: the logical byte + size of the file, and the transfer byte size used for the + transmission of the data. The transfer byte size is always 8 + bits. The transfer byte size is not necessarily the byte size + in which data is to be stored in a system, nor the logical byte + size for interpretation of the structure of the data. + + + +Postel & Reynolds [Page 3] + + + +RFC 959 October 1985 +File Transfer Protocol + + + control connection + + The communication path between the USER-PI and SERVER-PI for + the exchange of commands and replies. This connection follows + the Telnet Protocol. + + data connection + + A full duplex connection over which data is transferred, in a + specified mode and type. The data transferred may be a part of + a file, an entire file or a number of files. The path may be + between a server-DTP and a user-DTP, or between two + server-DTPs. + + data port + + The passive data transfer process "listens" on the data port + for a connection from the active transfer process in order to + open the data connection. + + DTP + + The data transfer process establishes and manages the data + connection. The DTP can be passive or active. + + End-of-Line + + The end-of-line sequence defines the separation of printing + lines. The sequence is Carriage Return, followed by Line Feed. + + EOF + + The end-of-file condition that defines the end of a file being + transferred. + + EOR + + The end-of-record condition that defines the end of a record + being transferred. + + error recovery + + A procedure that allows a user to recover from certain errors + such as failure of either host system or transfer process. In + FTP, error recovery may involve restarting a file transfer at a + given checkpoint. + + + +Postel & Reynolds [Page 4] + + + +RFC 959 October 1985 +File Transfer Protocol + + + FTP commands + + A set of commands that comprise the control information flowing + from the user-FTP to the server-FTP process. + + file + + An ordered set of computer data (including programs), of + arbitrary length, uniquely identified by a pathname. + + mode + + The mode in which data is to be transferred via the data + connection. The mode defines the data format during transfer + including EOR and EOF. The transfer modes defined in FTP are + described in the Section on Transmission Modes. + + NVT + + The Network Virtual Terminal as defined in the Telnet Protocol. + + NVFS + + The Network Virtual File System. A concept which defines a + standard network file system with standard commands and + pathname conventions. + + page + + A file may be structured as a set of independent parts called + pages. FTP supports the transmission of discontinuous files as + independent indexed pages. + + pathname + + Pathname is defined to be the character string which must be + input to a file system by a user in order to identify a file. + Pathname normally contains device and/or directory names, and + file name specification. FTP does not yet specify a standard + pathname convention. Each user must follow the file naming + conventions of the file systems involved in the transfer. + + PI + + The protocol interpreter. The user and server sides of the + protocol have distinct roles implemented in a user-PI and a + server-PI. + + +Postel & Reynolds [Page 5] + + + +RFC 959 October 1985 +File Transfer Protocol + + + record + + A sequential file may be structured as a number of contiguous + parts called records. Record structures are supported by FTP + but a file need not have record structure. + + reply + + A reply is an acknowledgment (positive or negative) sent from + server to user via the control connection in response to FTP + commands. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes + are for use by programs and the text is usually intended for + human users. + + server-DTP + + The data transfer process, in its normal "active" state, + establishes the data connection with the "listening" data port. + It sets up parameters for transfer and storage, and transfers + data on command from its PI. The DTP can be placed in a + "passive" state to listen for, rather than initiate a + connection on the data port. + + server-FTP process + + A process or set of processes which perform the function of + file transfer in cooperation with a user-FTP process and, + possibly, another server. The functions consist of a protocol + interpreter (PI) and a data transfer process (DTP). + + server-PI + + The server protocol interpreter "listens" on Port L for a + connection from a user-PI and establishes a control + communication connection. It receives standard FTP commands + from the user-PI, sends replies, and governs the server-DTP. + + type + + The data representation type used for data transfer and + storage. Type implies certain transformations between the time + of data storage and data transfer. The representation types + defined in FTP are described in the Section on Establishing + Data Connections. + + + + +Postel & Reynolds [Page 6] + + + +RFC 959 October 1985 +File Transfer Protocol + + + user + + A person or a process on behalf of a person wishing to obtain + file transfer service. The human user may interact directly + with a server-FTP process, but use of a user-FTP process is + preferred since the protocol design is weighted towards + automata. + + user-DTP + + The data transfer process "listens" on the data port for a + connection from a server-FTP process. If two servers are + transferring data between them, the user-DTP is inactive. + + user-FTP process + + A set of functions including a protocol interpreter, a data + transfer process and a user interface which together perform + the function of file transfer in cooperation with one or more + server-FTP processes. The user interface allows a local + language to be used in the command-reply dialogue with the + user. + + user-PI + + The user protocol interpreter initiates the control connection + from its port U to the server-FTP process, initiates FTP + commands, and governs the user-DTP if that process is part of + the file transfer. + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 7] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 2.3. THE FTP MODEL + + With the above definitions in mind, the following model (shown in + Figure 1) may be diagrammed for an FTP service. + + ------------- + |/---------\| + || User || -------- + ||Interface|<--->| User | + |\----^----/| -------- + ---------- | | | + |/------\| FTP Commands |/----V----\| + ||Server|<---------------->| User || + || PI || FTP Replies || PI || + |\--^---/| |\----^----/| + | | | | | | + -------- |/--V---\| Data |/----V----\| -------- + | File |<--->|Server|<---------------->| User |<--->| File | + |System| || DTP || Connection || DTP || |System| + -------- |\------/| |\---------/| -------- + ---------- ------------- + + Server-FTP USER-FTP + + NOTES: 1. The data connection may be used in either direction. + 2. The data connection need not exist all of the time. + + Figure 1 Model for FTP Use + + In the model described in Figure 1, the user-protocol interpreter + initiates the control connection. The control connection follows + the Telnet protocol. At the initiation of the user, standard FTP + commands are generated by the user-PI and transmitted to the + server process via the control connection. (The user may + establish a direct control connection to the server-FTP, from a + TAC terminal for example, and generate standard FTP commands + independently, bypassing the user-FTP process.) Standard replies + are sent from the server-PI to the user-PI over the control + connection in response to the commands. + + The FTP commands specify the parameters for the data connection + (data port, transfer mode, representation type, and structure) and + the nature of file system operation (store, retrieve, append, + delete, etc.). The user-DTP or its designate should "listen" on + the specified data port, and the server initiate the data + connection and data transfer in accordance with the specified + parameters. It should be noted that the data port need not be in + + +Postel & Reynolds [Page 8] + + + +RFC 959 October 1985 +File Transfer Protocol + + + the same host that initiates the FTP commands via the control + connection, but the user or the user-FTP process must ensure a + "listen" on the specified data port. It ought to also be noted + that the data connection may be used for simultaneous sending and + receiving. + + In another situation a user might wish to transfer files between + two hosts, neither of which is a local host. The user sets up + control connections to the two servers and then arranges for a + data connection between them. In this manner, control information + is passed to the user-PI but data is transferred between the + server data transfer processes. Following is a model of this + server-server interaction. + + + Control ------------ Control + ---------->| User-FTP |<----------- + | | User-PI | | + | | "C" | | + V ------------ V + -------------- -------------- + | Server-FTP | Data Connection | Server-FTP | + | "A" |<---------------------->| "B" | + -------------- Port (A) Port (B) -------------- + + + Figure 2 + + The protocol requires that the control connections be open while + data transfer is in progress. It is the responsibility of the + user to request the closing of the control connections when + finished using the FTP service, while it is the server who takes + the action. The server may abort data transfer if the control + connections are closed without command. + + The Relationship between FTP and Telnet: + + The FTP uses the Telnet protocol on the control connection. + This can be achieved in two ways: first, the user-PI or the + server-PI may implement the rules of the Telnet Protocol + directly in their own procedures; or, second, the user-PI or + the server-PI may make use of the existing Telnet module in the + system. + + Ease of implementaion, sharing code, and modular programming + argue for the second approach. Efficiency and independence + + + +Postel & Reynolds [Page 9] + + + +RFC 959 October 1985 +File Transfer Protocol + + + argue for the first approach. In practice, FTP relies on very + little of the Telnet Protocol, so the first approach does not + necessarily involve a large amount of code. + +3. DATA TRANSFER FUNCTIONS + + Files are transferred only via the data connection. The control + connection is used for the transfer of commands, which describe the + functions to be performed, and the replies to these commands (see the + Section on FTP Replies). Several commands are concerned with the + transfer of data between hosts. These data transfer commands include + the MODE command which specify how the bits of the data are to be + transmitted, and the STRUcture and TYPE commands, which are used to + define the way in which the data are to be represented. The + transmission and representation are basically independent but the + "Stream" transmission mode is dependent on the file structure + attribute and if "Compressed" transmission mode is used, the nature + of the filler byte depends on the representation type. + + 3.1. DATA REPRESENTATION AND STORAGE + + Data is transferred from a storage device in the sending host to a + storage device in the receiving host. Often it is necessary to + perform certain transformations on the data because data storage + representations in the two systems are different. For example, + NVT-ASCII has different data storage representations in different + systems. DEC TOPS-20s's generally store NVT-ASCII as five 7-bit + ASCII characters, left-justified in a 36-bit word. IBM Mainframe's + store NVT-ASCII as 8-bit EBCDIC codes. Multics stores NVT-ASCII + as four 9-bit characters in a 36-bit word. It is desirable to + convert characters into the standard NVT-ASCII representation when + transmitting text between dissimilar systems. The sending and + receiving sites would have to perform the necessary + transformations between the standard representation and their + internal representations. + + A different problem in representation arises when transmitting + binary data (not character codes) between host systems with + different word lengths. It is not always clear how the sender + should send data, and the receiver store it. For example, when + transmitting 32-bit bytes from a 32-bit word-length system to a + 36-bit word-length system, it may be desirable (for reasons of + efficiency and usefulness) to store the 32-bit bytes + right-justified in a 36-bit word in the latter system. In any + case, the user should have the option of specifying data + representation and transformation functions. It should be noted + + + +Postel & Reynolds [Page 10] + + + +RFC 959 October 1985 +File Transfer Protocol + + + that FTP provides for very limited data type representations. + Transformations desired beyond this limited capability should be + performed by the user directly. + + 3.1.1. DATA TYPES + + Data representations are handled in FTP by a user specifying a + representation type. This type may implicitly (as in ASCII or + EBCDIC) or explicitly (as in Local byte) define a byte size for + interpretation which is referred to as the "logical byte size." + Note that this has nothing to do with the byte size used for + transmission over the data connection, called the "transfer + byte size", and the two should not be confused. For example, + NVT-ASCII has a logical byte size of 8 bits. If the type is + Local byte, then the TYPE command has an obligatory second + parameter specifying the logical byte size. The transfer byte + size is always 8 bits. + + 3.1.1.1. ASCII TYPE + + This is the default type and must be accepted by all FTP + implementations. It is intended primarily for the transfer + of text files, except when both hosts would find the EBCDIC + type more convenient. + + The sender converts the data from an internal character + representation to the standard 8-bit NVT-ASCII + representation (see the Telnet specification). The receiver + will convert the data from the standard form to his own + internal form. + + In accordance with the NVT standard, the sequence + should be used where necessary to denote the end of a line + of text. (See the discussion of file structure at the end + of the Section on Data Representation and Storage.) + + Using the standard NVT-ASCII representation means that data + must be interpreted as 8-bit bytes. + + The Format parameter for ASCII and EBCDIC types is discussed + below. + + + + + + + + +Postel & Reynolds [Page 11] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 3.1.1.2. EBCDIC TYPE + + This type is intended for efficient transfer between hosts + which use EBCDIC for their internal character + representation. + + For transmission, the data are represented as 8-bit EBCDIC + characters. The character code is the only difference + between the functional specifications of EBCDIC and ASCII + types. + + End-of-line (as opposed to end-of-record--see the discussion + of structure) will probably be rarely used with EBCDIC type + for purposes of denoting structure, but where it is + necessary the character should be used. + + 3.1.1.3. IMAGE TYPE + + The data are sent as contiguous bits which, for transfer, + are packed into the 8-bit transfer bytes. The receiving + site must store the data as contiguous bits. The structure + of the storage system might necessitate the padding of the + file (or of each record, for a record-structured file) to + some convenient boundary (byte, word or block). This + padding, which must be all zeros, may occur only at the end + of the file (or at the end of each record) and there must be + a way of identifying the padding bits so that they may be + stripped off if the file is retrieved. The padding + transformation should be well publicized to enable a user to + process a file at the storage site. + + Image type is intended for the efficient storage and + retrieval of files and for the transfer of binary data. It + is recommended that this type be accepted by all FTP + implementations. + + 3.1.1.4. LOCAL TYPE + + The data is transferred in logical bytes of the size + specified by the obligatory second parameter, Byte size. + The value of Byte size must be a decimal integer; there is + no default value. The logical byte size is not necessarily + the same as the transfer byte size. If there is a + difference in byte sizes, then the logical bytes should be + packed contiguously, disregarding transfer byte boundaries + and with any necessary padding at the end. + + + +Postel & Reynolds [Page 12] + + + +RFC 959 October 1985 +File Transfer Protocol + + + When the data reaches the receiving host, it will be + transformed in a manner dependent on the logical byte size + and the particular host. This transformation must be + invertible (i.e., an identical file can be retrieved if the + same parameters are used) and should be well publicized by + the FTP implementors. + + For example, a user sending 36-bit floating-point numbers to + a host with a 32-bit word could send that data as Local byte + with a logical byte size of 36. The receiving host would + then be expected to store the logical bytes so that they + could be easily manipulated; in this example putting the + 36-bit logical bytes into 64-bit double words should + suffice. + + In another example, a pair of hosts with a 36-bit word size + may send data to one another in words by using TYPE L 36. + The data would be sent in the 8-bit transmission bytes + packed so that 9 transmission bytes carried two host words. + + 3.1.1.5. FORMAT CONTROL + + The types ASCII and EBCDIC also take a second (optional) + parameter; this is to indicate what kind of vertical format + control, if any, is associated with a file. The following + data representation types are defined in FTP: + + A character file may be transferred to a host for one of + three purposes: for printing, for storage and later + retrieval, or for processing. If a file is sent for + printing, the receiving host must know how the vertical + format control is represented. In the second case, it must + be possible to store a file at a host and then retrieve it + later in exactly the same form. Finally, it should be + possible to move a file from one host to another and process + the file at the second host without undue trouble. A single + ASCII or EBCDIC format does not satisfy all these + conditions. Therefore, these types have a second parameter + specifying one of the following three formats: + + 3.1.1.5.1. NON PRINT + + This is the default format to be used if the second + (format) parameter is omitted. Non-print format must be + accepted by all FTP implementations. + + + + +Postel & Reynolds [Page 13] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The file need contain no vertical format information. If + it is passed to a printer process, this process may + assume standard values for spacing and margins. + + Normally, this format will be used with files destined + for processing or just storage. + + 3.1.1.5.2. TELNET FORMAT CONTROLS + + The file contains ASCII/EBCDIC vertical format controls + (i.e., , , , , ) which the printer + process will interpret appropriately. , in exactly + this sequence, also denotes end-of-line. + + 3.1.1.5.2. CARRIAGE CONTROL (ASA) + + The file contains ASA (FORTRAN) vertical format control + characters. (See RFC 740 Appendix C; and Communications + of the ACM, Vol. 7, No. 10, p. 606, October 1964.) In a + line or a record formatted according to the ASA Standard, + the first character is not to be printed. Instead, it + should be used to determine the vertical movement of the + paper which should take place before the rest of the + record is printed. + + The ASA Standard specifies the following control + characters: + + Character Vertical Spacing + + blank Move paper up one line + 0 Move paper up two lines + 1 Move paper to top of next page + + No movement, i.e., overprint + + Clearly there must be some way for a printer process to + distinguish the end of the structural entity. If a file + has record structure (see below) this is no problem; + records will be explicitly marked during transfer and + storage. If the file has no record structure, the + end-of-line sequence is used to separate printing lines, + but these format effectors are overridden by the ASA + controls. + + + + + + +Postel & Reynolds [Page 14] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 3.1.2. DATA STRUCTURES + + In addition to different representation types, FTP allows the + structure of a file to be specified. Three file structures are + defined in FTP: + + file-structure, where there is no internal structure and + the file is considered to be a + continuous sequence of data bytes, + + record-structure, where the file is made up of sequential + records, + + and page-structure, where the file is made up of independent + indexed pages. + + File-structure is the default to be assumed if the STRUcture + command has not been used but both file and record structures + must be accepted for "text" files (i.e., files with TYPE ASCII + or EBCDIC) by all FTP implementations. The structure of a file + will affect both the transfer mode of a file (see the Section + on Transmission Modes) and the interpretation and storage of + the file. + + The "natural" structure of a file will depend on which host + stores the file. A source-code file will usually be stored on + an IBM Mainframe in fixed length records but on a DEC TOPS-20 + as a stream of characters partitioned into lines, for example + by . If the transfer of files between such disparate + sites is to be useful, there must be some way for one site to + recognize the other's assumptions about the file. + + With some sites being naturally file-oriented and others + naturally record-oriented there may be problems if a file with + one structure is sent to a host oriented to the other. If a + text file is sent with record-structure to a host which is file + oriented, then that host should apply an internal + transformation to the file based on the record structure. + Obviously, this transformation should be useful, but it must + also be invertible so that an identical file may be retrieved + using record structure. + + In the case of a file being sent with file-structure to a + record-oriented host, there exists the question of what + criteria the host should use to divide the file into records + which can be processed locally. If this division is necessary, + the FTP implementation should use the end-of-line sequence, + + +Postel & Reynolds [Page 15] + + + +RFC 959 October 1985 +File Transfer Protocol + + + for ASCII, or for EBCDIC text files, as the + delimiter. If an FTP implementation adopts this technique, it + must be prepared to reverse the transformation if the file is + retrieved with file-structure. + + 3.1.2.1. FILE STRUCTURE + + File structure is the default to be assumed if the STRUcture + command has not been used. + + In file-structure there is no internal structure and the + file is considered to be a continuous sequence of data + bytes. + + 3.1.2.2. RECORD STRUCTURE + + Record structures must be accepted for "text" files (i.e., + files with TYPE ASCII or EBCDIC) by all FTP implementations. + + In record-structure the file is made up of sequential + records. + + 3.1.2.3. PAGE STRUCTURE + + To transmit files that are discontinuous, FTP defines a page + structure. Files of this type are sometimes known as + "random access files" or even as "holey files". In these + files there is sometimes other information associated with + the file as a whole (e.g., a file descriptor), or with a + section of the file (e.g., page access controls), or both. + In FTP, the sections of the file are called pages. + + To provide for various page sizes and associated + information, each page is sent with a page header. The page + header has the following defined fields: + + Header Length + + The number of logical bytes in the page header + including this byte. The minimum header length is 4. + + Page Index + + The logical page number of this section of the file. + This is not the transmission sequence number of this + page, but the index used to identify this page of the + file. + + +Postel & Reynolds [Page 16] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Data Length + + The number of logical bytes in the page data. The + minimum data length is 0. + + Page Type + + The type of page this is. The following page types + are defined: + + 0 = Last Page + + This is used to indicate the end of a paged + structured transmission. The header length must + be 4, and the data length must be 0. + + 1 = Simple Page + + This is the normal type for simple paged files + with no page level associated control + information. The header length must be 4. + + 2 = Descriptor Page + + This type is used to transmit the descriptive + information for the file as a whole. + + 3 = Access Controlled Page + + This type includes an additional header field + for paged files with page level access control + information. The header length must be 5. + + Optional Fields + + Further header fields may be used to supply per page + control information, for example, per page access + control. + + All fields are one logical byte in length. The logical byte + size is specified by the TYPE command. See Appendix I for + further details and a specific case at the page structure. + + A note of caution about parameters: a file must be stored and + retrieved with the same parameters if the retrieved version is to + + + + +Postel & Reynolds [Page 17] + + + +RFC 959 October 1985 +File Transfer Protocol + + + be identical to the version originally transmitted. Conversely, + FTP implementations must return a file identical to the original + if the parameters used to store and retrieve a file are the same. + + 3.2. ESTABLISHING DATA CONNECTIONS + + The mechanics of transferring data consists of setting up the data + connection to the appropriate ports and choosing the parameters + for transfer. Both the user and the server-DTPs have a default + data port. The user-process default data port is the same as the + control connection port (i.e., U). The server-process default + data port is the port adjacent to the control connection port + (i.e., L-1). + + The transfer byte size is 8-bit bytes. This byte size is relevant + only for the actual transfer of the data; it has no bearing on + representation of the data within a host's file system. + + The passive data transfer process (this may be a user-DTP or a + second server-DTP) shall "listen" on the data port prior to + sending a transfer request command. The FTP request command + determines the direction of the data transfer. The server, upon + receiving the transfer request, will initiate the data connection + to the port. When the connection is established, the data + transfer begins between DTP's, and the server-PI sends a + confirming reply to the user-PI. + + Every FTP implementation must support the use of the default data + ports, and only the USER-PI can initiate a change to non-default + ports. + + It is possible for the user to specify an alternate data port by + use of the PORT command. The user may want a file dumped on a TAC + line printer or retrieved from a third party host. In the latter + case, the user-PI sets up control connections with both + server-PI's. One server is then told (by an FTP command) to + "listen" for a connection which the other will initiate. The + user-PI sends one server-PI a PORT command indicating the data + port of the other. Finally, both are sent the appropriate + transfer commands. The exact sequence of commands and replies + sent between the user-controller and the servers is defined in the + Section on FTP Replies. + + In general, it is the server's responsibility to maintain the data + connection--to initiate it and to close it. The exception to this + + + + +Postel & Reynolds [Page 18] + + + +RFC 959 October 1985 +File Transfer Protocol + + + is when the user-DTP is sending the data in a transfer mode that + requires the connection to be closed to indicate EOF. The server + MUST close the data connection under the following conditions: + + 1. The server has completed sending data in a transfer mode + that requires a close to indicate EOF. + + 2. The server receives an ABORT command from the user. + + 3. The port specification is changed by a command from the + user. + + 4. The control connection is closed legally or otherwise. + + 5. An irrecoverable error condition occurs. + + Otherwise the close is a server option, the exercise of which the + server must indicate to the user-process by either a 250 or 226 + reply only. + + 3.3. DATA CONNECTION MANAGEMENT + + Default Data Connection Ports: All FTP implementations must + support use of the default data connection ports, and only the + User-PI may initiate the use of non-default ports. + + Negotiating Non-Default Data Ports: The User-PI may specify a + non-default user side data port with the PORT command. The + User-PI may request the server side to identify a non-default + server side data port with the PASV command. Since a connection + is defined by the pair of addresses, either of these actions is + enough to get a different data connection, still it is permitted + to do both commands to use new ports on both ends of the data + connection. + + Reuse of the Data Connection: When using the stream mode of data + transfer the end of the file must be indicated by closing the + connection. This causes a problem if multiple files are to be + transfered in the session, due to need for TCP to hold the + connection record for a time out period to guarantee the reliable + communication. Thus the connection can not be reopened at once. + + There are two solutions to this problem. The first is to + negotiate a non-default port. The second is to use another + transfer mode. + + A comment on transfer modes. The stream transfer mode is + + +Postel & Reynolds [Page 19] + + + +RFC 959 October 1985 +File Transfer Protocol + + + inherently unreliable, since one can not determine if the + connection closed prematurely or not. The other transfer modes + (Block, Compressed) do not close the connection to indicate the + end of file. They have enough FTP encoding that the data + connection can be parsed to determine the end of the file. + Thus using these modes one can leave the data connection open + for multiple file transfers. + + 3.4. TRANSMISSION MODES + + The next consideration in transferring data is choosing the + appropriate transmission mode. There are three modes: one which + formats the data and allows for restart procedures; one which also + compresses the data for efficient transfer; and one which passes + the data with little or no processing. In this last case the mode + interacts with the structure attribute to determine the type of + processing. In the compressed mode, the representation type + determines the filler byte. + + All data transfers must be completed with an end-of-file (EOF) + which may be explicitly stated or implied by the closing of the + data connection. For files with record structure, all the + end-of-record markers (EOR) are explicit, including the final one. + For files transmitted in page structure a "last-page" page type is + used. + + NOTE: In the rest of this section, byte means "transfer byte" + except where explicitly stated otherwise. + + For the purpose of standardized transfer, the sending host will + translate its internal end of line or end of record denotation + into the representation prescribed by the transfer mode and file + structure, and the receiving host will perform the inverse + translation to its internal denotation. An IBM Mainframe record + count field may not be recognized at another host, so the + end-of-record information may be transferred as a two byte control + code in Stream mode or as a flagged bit in a Block or Compressed + mode descriptor. End-of-line in an ASCII or EBCDIC file with no + record structure should be indicated by or , + respectively. Since these transformations imply extra work for + some systems, identical systems transferring non-record structured + text files might wish to use a binary representation and stream + mode for the transfer. + + + + + + +Postel & Reynolds [Page 20] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The following transmission modes are defined in FTP: + + 3.4.1. STREAM MODE + + The data is transmitted as a stream of bytes. There is no + restriction on the representation type used; record structures + are allowed. + + In a record structured file EOR and EOF will each be indicated + by a two-byte control code. The first byte of the control code + will be all ones, the escape character. The second byte will + have the low order bit on and zeros elsewhere for EOR and the + second low order bit on for EOF; that is, the byte will have + value 1 for EOR and value 2 for EOF. EOR and EOF may be + indicated together on the last byte transmitted by turning both + low order bits on (i.e., the value 3). If a byte of all ones + was intended to be sent as data, it should be repeated in the + second byte of the control code. + + If the structure is a file structure, the EOF is indicated by + the sending host closing the data connection and all bytes are + data bytes. + + 3.4.2. BLOCK MODE + + The file is transmitted as a series of data blocks preceded by + one or more header bytes. The header bytes contain a count + field, and descriptor code. The count field indicates the + total length of the data block in bytes, thus marking the + beginning of the next data block (there are no filler bits). + The descriptor code defines: last block in the file (EOF) last + block in the record (EOR), restart marker (see the Section on + Error Recovery and Restart) or suspect data (i.e., the data + being transferred is suspected of errors and is not reliable). + This last code is NOT intended for error control within FTP. + It is motivated by the desire of sites exchanging certain types + of data (e.g., seismic or weather data) to send and receive all + the data despite local errors (such as "magnetic tape read + errors"), but to indicate in the transmission that certain + portions are suspect). Record structures are allowed in this + mode, and any representation type may be used. + + The header consists of the three bytes. Of the 24 bits of + header information, the 16 low order bits shall represent byte + count, and the 8 high order bits shall represent descriptor + codes as shown below. + + + +Postel & Reynolds [Page 21] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Block Header + + +----------------+----------------+----------------+ + | Descriptor | Byte Count | + | 8 bits | 16 bits | + +----------------+----------------+----------------+ + + + The descriptor codes are indicated by bit flags in the + descriptor byte. Four codes have been assigned, where each + code number is the decimal value of the corresponding bit in + the byte. + + Code Meaning + + 128 End of data block is EOR + 64 End of data block is EOF + 32 Suspected errors in data block + 16 Data block is a restart marker + + With this encoding, more than one descriptor coded condition + may exist for a particular block. As many bits as necessary + may be flagged. + + The restart marker is embedded in the data stream as an + integral number of 8-bit bytes representing printable + characters in the language being used over the control + connection (e.g., default--NVT-ASCII). (Space, in the + appropriate language) must not be used WITHIN a restart marker. + + For example, to transmit a six-character marker, the following + would be sent: + + +--------+--------+--------+ + |Descrptr| Byte count | + |code= 16| = 6 | + +--------+--------+--------+ + + +--------+--------+--------+ + | Marker | Marker | Marker | + | 8 bits | 8 bits | 8 bits | + +--------+--------+--------+ + + +--------+--------+--------+ + | Marker | Marker | Marker | + | 8 bits | 8 bits | 8 bits | + +--------+--------+--------+ + + +Postel & Reynolds [Page 22] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 3.4.3. COMPRESSED MODE + + There are three kinds of information to be sent: regular data, + sent in a byte string; compressed data, consisting of + replications or filler; and control information, sent in a + two-byte escape sequence. If n>0 bytes (up to 127) of regular + data are sent, these n bytes are preceded by a byte with the + left-most bit set to 0 and the right-most 7 bits containing the + number n. + + Byte string: + + 1 7 8 8 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + |0| n | | d(1) | ... | d(n) | + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + ^ ^ + |---n bytes---| + of data + + String of n data bytes d(1),..., d(n) + Count n must be positive. + + To compress a string of n replications of the data byte d, the + following 2 bytes are sent: + + Replicated Byte: + + 2 6 8 + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + |1 0| n | | d | + +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ + + A string of n filler bytes can be compressed into a single + byte, where the filler byte varies with the representation + type. If the type is ASCII or EBCDIC the filler byte is + (Space, ASCII code 32, EBCDIC code 64). If the type is Image + or Local byte the filler is a zero byte. + + Filler String: + + 2 6 + +-+-+-+-+-+-+-+-+ + |1 1| n | + +-+-+-+-+-+-+-+-+ + + The escape sequence is a double byte, the first of which is the + + +Postel & Reynolds [Page 23] + + + +RFC 959 October 1985 +File Transfer Protocol + + + escape byte (all zeros) and the second of which contains + descriptor codes as defined in Block mode. The descriptor + codes have the same meaning as in Block mode and apply to the + succeeding string of bytes. + + Compressed mode is useful for obtaining increased bandwidth on + very large network transmissions at a little extra CPU cost. + It can be most effectively used to reduce the size of printer + files such as those generated by RJE hosts. + + 3.5. ERROR RECOVERY AND RESTART + + There is no provision for detecting bits lost or scrambled in data + transfer; this level of error control is handled by the TCP. + However, a restart procedure is provided to protect users from + gross system failures (including failures of a host, an + FTP-process, or the underlying network). + + The restart procedure is defined only for the block and compressed + modes of data transfer. It requires the sender of data to insert + a special marker code in the data stream with some marker + information. The marker information has meaning only to the + sender, but must consist of printable characters in the default or + negotiated language of the control connection (ASCII or EBCDIC). + The marker could represent a bit-count, a record-count, or any + other information by which a system may identify a data + checkpoint. The receiver of data, if it implements the restart + procedure, would then mark the corresponding position of this + marker in the receiving system, and return this information to the + user. + + In the event of a system failure, the user can restart the data + transfer by identifying the marker point with the FTP restart + procedure. The following example illustrates the use of the + restart procedure. + + The sender of the data inserts an appropriate marker block in the + data stream at a convenient point. The receiving host marks the + corresponding data point in its file system and conveys the last + known sender and receiver marker information to the user, either + directly or over the control connection in a 110 reply (depending + on who is the sender). In the event of a system failure, the user + or controller process restarts the server at the last server + marker by sending a restart command with server's marker code as + its argument. The restart command is transmitted over the control + + + + +Postel & Reynolds [Page 24] + + + +RFC 959 October 1985 +File Transfer Protocol + + + connection and is immediately followed by the command (such as + RETR, STOR or LIST) which was being executed when the system + failure occurred. + +4. FILE TRANSFER FUNCTIONS + + The communication channel from the user-PI to the server-PI is + established as a TCP connection from the user to the standard server + port. The user protocol interpreter is responsible for sending FTP + commands and interpreting the replies received; the server-PI + interprets commands, sends replies and directs its DTP to set up the + data connection and transfer the data. If the second party to the + data transfer (the passive transfer process) is the user-DTP, then it + is governed through the internal protocol of the user-FTP host; if it + is a second server-DTP, then it is governed by its PI on command from + the user-PI. The FTP replies are discussed in the next section. In + the description of a few of the commands in this section, it is + helpful to be explicit about the possible replies. + + 4.1. FTP COMMANDS + + 4.1.1. ACCESS CONTROL COMMANDS + + The following commands specify access control identifiers + (command codes are shown in parentheses). + + USER NAME (USER) + + The argument field is a Telnet string identifying the user. + The user identification is that which is required by the + server for access to its file system. This command will + normally be the first command transmitted by the user after + the control connections are made (some servers may require + this). Additional identification information in the form of + a password and/or an account command may also be required by + some servers. Servers may allow a new USER command to be + entered at any point in order to change the access control + and/or accounting information. This has the effect of + flushing any user, password, and account information already + supplied and beginning the login sequence again. All + transfer parameters are unchanged and any file transfer in + progress is completed under the old access control + parameters. + + + + + + +Postel & Reynolds [Page 25] + + + +RFC 959 October 1985 +File Transfer Protocol + + + PASSWORD (PASS) + + The argument field is a Telnet string specifying the user's + password. This command must be immediately preceded by the + user name command, and, for some sites, completes the user's + identification for access control. Since password + information is quite sensitive, it is desirable in general + to "mask" it or suppress typeout. It appears that the + server has no foolproof way to achieve this. It is + therefore the responsibility of the user-FTP process to hide + the sensitive password information. + + ACCOUNT (ACCT) + + The argument field is a Telnet string identifying the user's + account. The command is not necessarily related to the USER + command, as some sites may require an account for login and + others only for specific access, such as storing files. In + the latter case the command may arrive at any time. + + There are reply codes to differentiate these cases for the + automation: when account information is required for login, + the response to a successful PASSword command is reply code + 332. On the other hand, if account information is NOT + required for login, the reply to a successful PASSword + command is 230; and if the account information is needed for + a command issued later in the dialogue, the server should + return a 332 or 532 reply depending on whether it stores + (pending receipt of the ACCounT command) or discards the + command, respectively. + + CHANGE WORKING DIRECTORY (CWD) + + This command allows the user to work with a different + directory or dataset for file storage or retrieval without + altering his login or accounting information. Transfer + parameters are similarly unchanged. The argument is a + pathname specifying a directory or other system dependent + file group designator. + + CHANGE TO PARENT DIRECTORY (CDUP) + + This command is a special case of CWD, and is included to + simplify the implementation of programs for transferring + directory trees between operating systems having different + + + + +Postel & Reynolds [Page 26] + + + +RFC 959 October 1985 +File Transfer Protocol + + + syntaxes for naming the parent directory. The reply codes + shall be identical to the reply codes of CWD. See + Appendix II for further details. + + STRUCTURE MOUNT (SMNT) + + This command allows the user to mount a different file + system data structure without altering his login or + accounting information. Transfer parameters are similarly + unchanged. The argument is a pathname specifying a + directory or other system dependent file group designator. + + REINITIALIZE (REIN) + + This command terminates a USER, flushing all I/O and account + information, except to allow any transfer in progress to be + completed. All parameters are reset to the default settings + and the control connection is left open. This is identical + to the state in which a user finds himself immediately after + the control connection is opened. A USER command may be + expected to follow. + + LOGOUT (QUIT) + + This command terminates a USER and if file transfer is not + in progress, the server closes the control connection. If + file transfer is in progress, the connection will remain + open for result response and the server will then close it. + If the user-process is transferring files for several USERs + but does not wish to close and then reopen connections for + each, then the REIN command should be used instead of QUIT. + + An unexpected close on the control connection will cause the + server to take the effective action of an abort (ABOR) and a + logout (QUIT). + + 4.1.2. TRANSFER PARAMETER COMMANDS + + All data transfer parameters have default values, and the + commands specifying data transfer parameters are required only + if the default parameter values are to be changed. The default + value is the last specified value, or if no value has been + specified, the standard default value is as stated here. This + implies that the server must "remember" the applicable default + values. The commands may be in any order except that they must + precede the FTP service request. The following commands + specify data transfer parameters: + + +Postel & Reynolds [Page 27] + + + +RFC 959 October 1985 +File Transfer Protocol + + + DATA PORT (PORT) + + The argument is a HOST-PORT specification for the data port + to be used in data connection. There are defaults for both + the user and server data ports, and under normal + circumstances this command and its reply are not needed. If + this command is used, the argument is the concatenation of a + 32-bit internet host address and a 16-bit TCP port address. + This address information is broken into 8-bit fields and the + value of each field is transmitted as a decimal number (in + character string representation). The fields are separated + by commas. A port command would be: + + PORT h1,h2,h3,h4,p1,p2 + + where h1 is the high order 8 bits of the internet host + address. + + PASSIVE (PASV) + + This command requests the server-DTP to "listen" on a data + port (which is not its default data port) and to wait for a + connection rather than initiate one upon receipt of a + transfer command. The response to this command includes the + host and port address this server is listening on. + + REPRESENTATION TYPE (TYPE) + + The argument specifies the representation type as described + in the Section on Data Representation and Storage. Several + types take a second parameter. The first parameter is + denoted by a single Telnet character, as is the second + Format parameter for ASCII and EBCDIC; the second parameter + for local byte is a decimal integer to indicate Bytesize. + The parameters are separated by a (Space, ASCII code + 32). + + The following codes are assigned for type: + + \ / + A - ASCII | | N - Non-print + |-><-| T - Telnet format effectors + E - EBCDIC| | C - Carriage Control (ASA) + / \ + I - Image + + L - Local byte Byte size + + +Postel & Reynolds [Page 28] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The default representation type is ASCII Non-print. If the + Format parameter is changed, and later just the first + argument is changed, Format then returns to the Non-print + default. + + FILE STRUCTURE (STRU) + + The argument is a single Telnet character code specifying + file structure described in the Section on Data + Representation and Storage. + + The following codes are assigned for structure: + + F - File (no record structure) + R - Record structure + P - Page structure + + The default structure is File. + + TRANSFER MODE (MODE) + + The argument is a single Telnet character code specifying + the data transfer modes described in the Section on + Transmission Modes. + + The following codes are assigned for transfer modes: + + S - Stream + B - Block + C - Compressed + + The default transfer mode is Stream. + + 4.1.3. FTP SERVICE COMMANDS + + The FTP service commands define the file transfer or the file + system function requested by the user. The argument of an FTP + service command will normally be a pathname. The syntax of + pathnames must conform to server site conventions (with + standard defaults applicable), and the language conventions of + the control connection. The suggested default handling is to + use the last specified device, directory or file name, or the + standard default defined for local users. The commands may be + in any order except that a "rename from" command must be + followed by a "rename to" command and the restart command must + be followed by the interrupted service command (e.g., STOR or + RETR). The data, when transferred in response to FTP service + + +Postel & Reynolds [Page 29] + + + +RFC 959 October 1985 +File Transfer Protocol + + + commands, shall always be sent over the data connection, except + for certain informative replies. The following commands + specify FTP service requests: + + RETRIEVE (RETR) + + This command causes the server-DTP to transfer a copy of the + file, specified in the pathname, to the server- or user-DTP + at the other end of the data connection. The status and + contents of the file at the server site shall be unaffected. + + STORE (STOR) + + This command causes the server-DTP to accept the data + transferred via the data connection and to store the data as + a file at the server site. If the file specified in the + pathname exists at the server site, then its contents shall + be replaced by the data being transferred. A new file is + created at the server site if the file specified in the + pathname does not already exist. + + STORE UNIQUE (STOU) + + This command behaves like STOR except that the resultant + file is to be created in the current directory under a name + unique to that directory. The 250 Transfer Started response + must include the name generated. + + APPEND (with create) (APPE) + + This command causes the server-DTP to accept the data + transferred via the data connection and to store the data in + a file at the server site. If the file specified in the + pathname exists at the server site, then the data shall be + appended to that file; otherwise the file specified in the + pathname shall be created at the server site. + + ALLOCATE (ALLO) + + This command may be required by some servers to reserve + sufficient storage to accommodate the new file to be + transferred. The argument shall be a decimal integer + representing the number of bytes (using the logical byte + size) of storage to be reserved for the file. For files + sent with record or page structure a maximum record or page + size (in logical bytes) might also be necessary; this is + indicated by a decimal integer in a second argument field of + + +Postel & Reynolds [Page 30] + + + +RFC 959 October 1985 +File Transfer Protocol + + + the command. This second argument is optional, but when + present should be separated from the first by the three + Telnet characters R . This command shall be + followed by a STORe or APPEnd command. The ALLO command + should be treated as a NOOP (no operation) by those servers + which do not require that the maximum size of the file be + declared beforehand, and those servers interested in only + the maximum record or page size should accept a dummy value + in the first argument and ignore it. + + RESTART (REST) + + The argument field represents the server marker at which + file transfer is to be restarted. This command does not + cause file transfer but skips over the file to the specified + data checkpoint. This command shall be immediately followed + by the appropriate FTP service command which shall cause + file transfer to resume. + + RENAME FROM (RNFR) + + This command specifies the old pathname of the file which is + to be renamed. This command must be immediately followed by + a "rename to" command specifying the new file pathname. + + RENAME TO (RNTO) + + This command specifies the new pathname of the file + specified in the immediately preceding "rename from" + command. Together the two commands cause a file to be + renamed. + + ABORT (ABOR) + + This command tells the server to abort the previous FTP + service command and any associated transfer of data. The + abort command may require "special action", as discussed in + the Section on FTP Commands, to force recognition by the + server. No action is to be taken if the previous command + has been completed (including data transfer). The control + connection is not to be closed by the server, but the data + connection must be closed. + + There are two cases for the server upon receipt of this + command: (1) the FTP service command was already completed, + or (2) the FTP service command is still in progress. + + + +Postel & Reynolds [Page 31] + + + +RFC 959 October 1985 +File Transfer Protocol + + + In the first case, the server closes the data connection + (if it is open) and responds with a 226 reply, indicating + that the abort command was successfully processed. + + In the second case, the server aborts the FTP service in + progress and closes the data connection, returning a 426 + reply to indicate that the service request terminated + abnormally. The server then sends a 226 reply, + indicating that the abort command was successfully + processed. + + DELETE (DELE) + + This command causes the file specified in the pathname to be + deleted at the server site. If an extra level of protection + is desired (such as the query, "Do you really wish to + delete?"), it should be provided by the user-FTP process. + + REMOVE DIRECTORY (RMD) + + This command causes the directory specified in the pathname + to be removed as a directory (if the pathname is absolute) + or as a subdirectory of the current working directory (if + the pathname is relative). See Appendix II. + + MAKE DIRECTORY (MKD) + + This command causes the directory specified in the pathname + to be created as a directory (if the pathname is absolute) + or as a subdirectory of the current working directory (if + the pathname is relative). See Appendix II. + + PRINT WORKING DIRECTORY (PWD) + + This command causes the name of the current working + directory to be returned in the reply. See Appendix II. + + LIST (LIST) + + This command causes a list to be sent from the server to the + passive DTP. If the pathname specifies a directory or other + group of files, the server should transfer a list of files + in the specified directory. If the pathname specifies a + file then the server should send current information on the + file. A null argument implies the user's current working or + default directory. The data transfer is over the data + connection in type ASCII or type EBCDIC. (The user must + + +Postel & Reynolds [Page 32] + + + +RFC 959 October 1985 +File Transfer Protocol + + + ensure that the TYPE is appropriately ASCII or EBCDIC). + Since the information on a file may vary widely from system + to system, this information may be hard to use automatically + in a program, but may be quite useful to a human user. + + NAME LIST (NLST) + + This command causes a directory listing to be sent from + server to user site. The pathname should specify a + directory or other system-specific file group descriptor; a + null argument implies the current directory. The server + will return a stream of names of files and no other + information. The data will be transferred in ASCII or + EBCDIC type over the data connection as valid pathname + strings separated by or . (Again the user must + ensure that the TYPE is correct.) This command is intended + to return information that can be used by a program to + further process the files automatically. For example, in + the implementation of a "multiple get" function. + + SITE PARAMETERS (SITE) + + This command is used by the server to provide services + specific to his system that are essential to file transfer + but not sufficiently universal to be included as commands in + the protocol. The nature of these services and the + specification of their syntax can be stated in a reply to + the HELP SITE command. + + SYSTEM (SYST) + + This command is used to find out the type of operating + system at the server. The reply shall have as its first + word one of the system names listed in the current version + of the Assigned Numbers document [4]. + + STATUS (STAT) + + This command shall cause a status response to be sent over + the control connection in the form of a reply. The command + may be sent during a file transfer (along with the Telnet IP + and Synch signals--see the Section on FTP Commands) in which + case the server will respond with the status of the + operation in progress, or it may be sent between file + transfers. In the latter case, the command may have an + argument field. If the argument is a pathname, the command + is analogous to the "list" command except that data shall be + + +Postel & Reynolds [Page 33] + + + +RFC 959 October 1985 +File Transfer Protocol + + + transferred over the control connection. If a partial + pathname is given, the server may respond with a list of + file names or attributes associated with that specification. + If no argument is given, the server should return general + status information about the server FTP process. This + should include current values of all transfer parameters and + the status of connections. + + HELP (HELP) + + This command shall cause the server to send helpful + information regarding its implementation status over the + control connection to the user. The command may take an + argument (e.g., any command name) and return more specific + information as a response. The reply is type 211 or 214. + It is suggested that HELP be allowed before entering a USER + command. The server may use this reply to specify + site-dependent parameters, e.g., in response to HELP SITE. + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that the + server send an OK reply. + + The File Transfer Protocol follows the specifications of the Telnet + protocol for all communications over the control connection. Since + the language used for Telnet communication may be a negotiated + option, all references in the next two sections will be to the + "Telnet language" and the corresponding "Telnet end-of-line code". + Currently, one may take these to mean NVT-ASCII and . No other + specifications of the Telnet protocol will be cited. + + FTP commands are "Telnet strings" terminated by the "Telnet end of + line code". The command codes themselves are alphabetic characters + terminated by the character (Space) if parameters follow and + Telnet-EOL otherwise. The command codes and the semantics of + commands are described in this section; the detailed syntax of + commands is specified in the Section on Commands, the reply sequences + are discussed in the Section on Sequencing of Commands and Replies, + and scenarios illustrating the use of commands are provided in the + Section on Typical FTP Scenarios. + + FTP commands may be partitioned as those specifying access-control + identifiers, data transfer parameters, or FTP service requests. + Certain commands (such as ABOR, STAT, QUIT) may be sent over the + control connection while a data transfer is in progress. Some + + +Postel & Reynolds [Page 34] + + + +RFC 959 October 1985 +File Transfer Protocol + + + servers may not be able to monitor the control and data connections + simultaneously, in which case some special action will be necessary + to get the server's attention. The following ordered format is + tentatively recommended: + + 1. User system inserts the Telnet "Interrupt Process" (IP) signal + in the Telnet stream. + + 2. User system sends the Telnet "Synch" signal. + + 3. User system inserts the command (e.g., ABOR) in the Telnet + stream. + + 4. Server PI, after receiving "IP", scans the Telnet stream for + EXACTLY ONE FTP command. + + (For other servers this may not be necessary but the actions listed + above should have no unusual effect.) + + 4.2. FTP REPLIES + + Replies to File Transfer Protocol commands are devised to ensure + the synchronization of requests and actions in the process of file + transfer, and to guarantee that the user process always knows the + state of the Server. Every command must generate at least one + reply, although there may be more than one; in the latter case, + the multiple replies must be easily distinguished. In addition, + some commands occur in sequential groups, such as USER, PASS and + ACCT, or RNFR and RNTO. The replies show the existence of an + intermediate state if all preceding commands have been successful. + A failure at any point in the sequence necessitates the repetition + of the entire sequence from the beginning. + + The details of the command-reply sequence are made explicit in + a set of state diagrams below. + + An FTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is intended for the human user. It is intended + that the three digits contain enough encoded information that the + user-process (the User-PI) will not need to examine the text and + may either discard it or pass it on to the user, as appropriate. + In particular, the text may be server-dependent, so there are + likely to be varying texts for each reply code. + + A reply is defined to contain the 3-digit code, followed by Space + + +Postel & Reynolds [Page 35] + + + +RFC 959 October 1985 +File Transfer Protocol + + + , followed by one line of text (where some maximum line length + has been specified), and terminated by the Telnet end-of-line + code. There will be cases however, where the text is longer than + a single line. In these cases the complete text must be bracketed + so the User-process knows when it may stop reading the reply (i.e. + stop processing input on the control connection) and go do other + things. This requires a special format on the first line to + indicate that more than one line is coming, and another on the + last line to designate it as the last. At least one of these must + contain the appropriate reply code to indicate the state of the + transaction. To satisfy all factions, it was decided that both + the first and last line codes should be the same. + + Thus the format for multi-line replies is that the first line + will begin with the exact required reply code, followed + immediately by a Hyphen, "-" (also known as Minus), followed by + text. The last line will begin with the same code, followed + immediately by Space , optionally some text, and the Telnet + end-of-line code. + + For example: + 123-First line + Second line + 234 A line beginning with numbers + 123 The last line + + The user-process then simply needs to search for the second + occurrence of the same reply code, followed by (Space), at + the beginning of a line, and ignore all intermediary lines. If + an intermediary line begins with a 3-digit number, the Server + must pad the front to avoid confusion. + + This scheme allows standard system routines to be used for + reply information (such as for the STAT reply), with + "artificial" first and last lines tacked on. In rare cases + where these routines are able to generate three digits and a + Space at the beginning of any line, the beginning of each + text line should be offset by some neutral text, like Space. + + This scheme assumes that multi-line replies may not be nested. + + The three digits of the reply each have a special significance. + This is intended to allow a range of very simple to very + sophisticated responses by the user-process. The first digit + denotes whether the response is good, bad or incomplete. + (Referring to the state diagram), an unsophisticated user-process + will be able to determine its next action (proceed as planned, + + +Postel & Reynolds [Page 36] + + + +RFC 959 October 1985 +File Transfer Protocol + + + redo, retrench, etc.) by simply examining this first digit. A + user-process that wants to know approximately what kind of error + occurred (e.g. file system error, command syntax error) may + examine the second digit, reserving the third digit for the finest + gradation of information (e.g., RNTO command without a preceding + RNFR). + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The requested action is being initiated; expect another + reply before proceeding with a new command. (The + user-process sending another command before the + completion reply would be in violation of protocol; but + server-FTP processes should queue any commands that + arrive while a preceding command is in progress.) This + type of reply can be used to indicate that the command + was accepted and the user-process may now pay attention + to the data connections, for implementations where + simultaneous monitoring is difficult. The server-FTP + process may send at most, one 1yz reply per command. + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The user should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not take place, but the error condition is temporary and + the action may be requested again. The user should + return to the beginning of the command sequence, if any. + It is difficult to assign a meaning to "transient", + particularly when two distinct sites (Server- and + User-processes) have to agree on the interpretation. + Each reply in the 4yz category might have a slightly + different time value, but the intent is that the + + +Postel & Reynolds [Page 37] + + + +RFC 959 October 1985 +File Transfer Protocol + + + user-process is encouraged to try again. A rule of thumb + in determining if a reply fits into the 4yz or the 5yz + (Permanent Negative) category is that replies are 4yz if + the commands can be repeated without any change in + command form or in properties of the User or Server + (e.g., the command is spelled the same with the same + arguments used; the user does not change his file access + or user name; the server does not put up a new + implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not take place. The User-process is discouraged from + repeating the exact request (in the same sequence). Even + some "permanent" error conditions can be corrected, so + the human user may want to direct his User-process to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered his directory status.) + + The following function groupings are encoded in the second + digit: + + x0z Syntax - These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, unimplemented or superfluous + commands. + + x1z Information - These are replies to requests for + information, such as status or help. + + x2z Connections - Replies referring to the control and + data connections. + + x3z Authentication and accounting - Replies for the login + process and accounting procedures. + + x4z Unspecified as yet. + + x5z File system - These replies indicate the status of the + Server file system vis-a-vis the requested transfer or + other file system action. + + The third digit gives a finer gradation of meaning in each of + the function categories, specified by the second digit. The + list of replies below will illustrate this. Note that the text + + +Postel & Reynolds [Page 38] + + + +RFC 959 October 1985 +File Transfer Protocol + + + associated with each reply is recommended, rather than + mandatory, and may even change according to the command with + which it is associated. The reply codes, on the other hand, + must strictly follow the specifications in the last section; + that is, Server implementations should not invent new codes for + situations that are only slightly different from the ones + described here, but rather should adapt codes already defined. + + A command such as TYPE or ALLO whose successful execution + does not offer the user-process any new information will + cause a 200 reply to be returned. If the command is not + implemented by a particular Server-FTP process because it + has no relevance to that computer system, for example ALLO + at a TOPS20 site, a Positive Completion reply is still + desired so that the simple User-process knows it can proceed + with its course of action. A 202 reply is used in this case + with, for example, the reply text: "No storage allocation + necessary." If, on the other hand, the command requests a + non-site-specific action and is unimplemented, the response + is 502. A refinement of that is the 504 reply for a command + that is implemented, but that requests an unimplemented + parameter. + + 4.2.1 Reply Codes by Function Groups + + 200 Command okay. + 500 Syntax error, command unrecognized. + This may include errors such as command line too long. + 501 Syntax error in parameters or arguments. + 202 Command not implemented, superfluous at this site. + 502 Command not implemented. + 503 Bad sequence of commands. + 504 Command not implemented for that parameter. + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 39] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 110 Restart marker reply. + In this case, the text is exact and not left to the + particular implementation; it must read: + MARK yyyy = mmmm + Where yyyy is User-process data stream marker, and mmmm + server's equivalent marker (note the spaces between markers + and "="). + 211 System status, or system help reply. + 212 Directory status. + 213 File status. + 214 Help message. + On how to use the server or the meaning of a particular + non-standard command. This reply is useful only to the + human user. + 215 NAME system type. + Where NAME is an official system name from the list in the + Assigned Numbers document. + + 120 Service ready in nnn minutes. + 220 Service ready for new user. + 221 Service closing control connection. + Logged out if appropriate. + 421 Service not available, closing control connection. + This may be a reply to any command if the service knows it + must shut down. + 125 Data connection already open; transfer starting. + 225 Data connection open; no transfer in progress. + 425 Can't open data connection. + 226 Closing data connection. + Requested file action successful (for example, file + transfer or file abort). + 426 Connection closed; transfer aborted. + 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). + + 230 User logged in, proceed. + 530 Not logged in. + 331 User name okay, need password. + 332 Need account for login. + 532 Need account for storing files. + + + + + + + + + + +Postel & Reynolds [Page 40] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 150 File status okay; about to open data connection. + 250 Requested file action okay, completed. + 257 "PATHNAME" created. + 350 Requested file action pending further information. + 450 Requested file action not taken. + File unavailable (e.g., file busy). + 550 Requested action not taken. + File unavailable (e.g., file not found, no access). + 451 Requested action aborted. Local error in processing. + 551 Requested action aborted. Page type unknown. + 452 Requested action not taken. + Insufficient storage space in system. + 552 Requested file action aborted. + Exceeded storage allocation (for current directory or + dataset). + 553 Requested action not taken. + File name not allowed. + + + 4.2.2 Numeric Order List of Reply Codes + + 110 Restart marker reply. + In this case, the text is exact and not left to the + particular implementation; it must read: + MARK yyyy = mmmm + Where yyyy is User-process data stream marker, and mmmm + server's equivalent marker (note the spaces between markers + and "="). + 120 Service ready in nnn minutes. + 125 Data connection already open; transfer starting. + 150 File status okay; about to open data connection. + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 41] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 200 Command okay. + 202 Command not implemented, superfluous at this site. + 211 System status, or system help reply. + 212 Directory status. + 213 File status. + 214 Help message. + On how to use the server or the meaning of a particular + non-standard command. This reply is useful only to the + human user. + 215 NAME system type. + Where NAME is an official system name from the list in the + Assigned Numbers document. + 220 Service ready for new user. + 221 Service closing control connection. + Logged out if appropriate. + 225 Data connection open; no transfer in progress. + 226 Closing data connection. + Requested file action successful (for example, file + transfer or file abort). + 227 Entering Passive Mode (h1,h2,h3,h4,p1,p2). + 230 User logged in, proceed. + 250 Requested file action okay, completed. + 257 "PATHNAME" created. + + 331 User name okay, need password. + 332 Need account for login. + 350 Requested file action pending further information. + + 421 Service not available, closing control connection. + This may be a reply to any command if the service knows it + must shut down. + 425 Can't open data connection. + 426 Connection closed; transfer aborted. + 450 Requested file action not taken. + File unavailable (e.g., file busy). + 451 Requested action aborted: local error in processing. + 452 Requested action not taken. + Insufficient storage space in system. + + + + + + + + + + + +Postel & Reynolds [Page 42] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 500 Syntax error, command unrecognized. + This may include errors such as command line too long. + 501 Syntax error in parameters or arguments. + 502 Command not implemented. + 503 Bad sequence of commands. + 504 Command not implemented for that parameter. + 530 Not logged in. + 532 Need account for storing files. + 550 Requested action not taken. + File unavailable (e.g., file not found, no access). + 551 Requested action aborted: page type unknown. + 552 Requested file action aborted. + Exceeded storage allocation (for current directory or + dataset). + 553 Requested action not taken. + File name not allowed. + + +5. DECLARATIVE SPECIFICATIONS + + 5.1. MINIMUM IMPLEMENTATION + + In order to make FTP workable without needless error messages, the + following minimum implementation is required for all servers: + + TYPE - ASCII Non-print + MODE - Stream + STRUCTURE - File, Record + COMMANDS - USER, QUIT, PORT, + TYPE, MODE, STRU, + for the default values + RETR, STOR, + NOOP. + + The default values for transfer parameters are: + + TYPE - ASCII Non-print + MODE - Stream + STRU - File + + All hosts must accept the above as the standard defaults. + + + + + + + + +Postel & Reynolds [Page 43] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 5.2. CONNECTIONS + + The server protocol interpreter shall "listen" on Port L. The + user or user protocol interpreter shall initiate the full-duplex + control connection. Server- and user- processes should follow the + conventions of the Telnet protocol as specified in the + ARPA-Internet Protocol Handbook [1]. Servers are under no + obligation to provide for editing of command lines and may require + that it be done in the user host. The control connection shall be + closed by the server at the user's request after all transfers and + replies are completed. + + The user-DTP must "listen" on the specified data port; this may be + the default user port (U) or a port specified in the PORT command. + The server shall initiate the data connection from his own default + data port (L-1) using the specified user data port. The direction + of the transfer and the port used will be determined by the FTP + service command. + + Note that all FTP implementation must support data transfer using + the default port, and that only the USER-PI may initiate the use + of non-default ports. + + When data is to be transferred between two servers, A and B (refer + to Figure 2), the user-PI, C, sets up control connections with + both server-PI's. One of the servers, say A, is then sent a PASV + command telling him to "listen" on his data port rather than + initiate a connection when he receives a transfer service command. + When the user-PI receives an acknowledgment to the PASV command, + which includes the identity of the host and port being listened + on, the user-PI then sends A's port, a, to B in a PORT command; a + reply is returned. The user-PI may then send the corresponding + service commands to A and B. Server B initiates the connection + and the transfer proceeds. The command-reply sequence is listed + below where the messages are vertically synchronous but + horizontally asynchronous: + + + + + + + + + + + + + +Postel & Reynolds [Page 44] + + + +RFC 959 October 1985 +File Transfer Protocol + + + User-PI - Server A User-PI - Server B + ------------------ ------------------ + + C->A : Connect C->B : Connect + C->A : PASV + A->C : 227 Entering Passive Mode. A1,A2,A3,A4,a1,a2 + C->B : PORT A1,A2,A3,A4,a1,a2 + B->C : 200 Okay + C->A : STOR C->B : RETR + B->A : Connect to HOST-A, PORT-a + + Figure 3 + + The data connection shall be closed by the server under the + conditions described in the Section on Establishing Data + Connections. If the data connection is to be closed following a + data transfer where closing the connection is not required to + indicate the end-of-file, the server must do so immediately. + Waiting until after a new transfer command is not permitted + because the user-process will have already tested the data + connection to see if it needs to do a "listen"; (remember that the + user must "listen" on a closed data port BEFORE sending the + transfer request). To prevent a race condition here, the server + sends a reply (226) after closing the data connection (or if the + connection is left open, a "file transfer completed" reply (250) + and the user-PI should wait for one of these replies before + issuing a new transfer command). + + Any time either the user or server see that the connection is + being closed by the other side, it should promptly read any + remaining data queued on the connection and issue the close on its + own side. + + 5.3. COMMANDS + + The commands are Telnet character strings transmitted over the + control connections as described in the Section on FTP Commands. + The command functions and semantics are described in the Section + on Access Control Commands, Transfer Parameter Commands, FTP + Service Commands, and Miscellaneous Commands. The command syntax + is specified here. + + The commands begin with a command code followed by an argument + field. The command codes are four or fewer alphabetic characters. + Upper and lower case alphabetic characters are to be treated + identically. Thus, any of the following may represent the + retrieve command: + + +Postel & Reynolds [Page 45] + + + +RFC 959 October 1985 +File Transfer Protocol + + + RETR Retr retr ReTr rETr + + This also applies to any symbols representing parameter values, + such as A or a for ASCII TYPE. The command codes and the argument + fields are separated by one or more spaces. + + The argument field consists of a variable length character string + ending with the character sequence (Carriage Return, Line + Feed) for NVT-ASCII representation; for other negotiated languages + a different end of line character might be used. It should be + noted that the server is to take no action until the end of line + code is received. + + The syntax is specified below in NVT-ASCII. All characters in the + argument field are ASCII characters including any ASCII + represented decimal integers. Square brackets denote an optional + argument field. If the option is not taken, the appropriate + default is implied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 46] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 5.3.1. FTP COMMANDS + + The following are the FTP commands: + + USER + PASS + ACCT + CWD + CDUP + SMNT + QUIT + REIN + PORT + PASV + TYPE + STRU + MODE + RETR + STOR + STOU + APPE + ALLO + [ R ] + REST + RNFR + RNTO + ABOR + DELE + RMD + MKD + PWD + LIST [ ] + NLST [ ] + SITE + SYST + STAT [ ] + HELP [ ] + NOOP + + + + + + + + + + + +Postel & Reynolds [Page 47] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 5.3.2. FTP COMMAND ARGUMENTS + + The syntax of the above argument fields (using BNF notation + where applicable) is: + + ::= + ::= + ::= + ::= | + ::= any of the 128 ASCII characters except and + + ::= + ::= | + ::= printable characters, any + ASCII code 33 through 126 + ::= + ::= , + ::= ,,, + ::= , + ::= any decimal integer 1 through 255 + ::= N | T | C + ::= A [ ] + | E [ ] + | I + | L + ::= F | R | P + ::= S | B | C + ::= + ::= any decimal integer + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 48] + + + +RFC 959 October 1985 +File Transfer Protocol + + + 5.4. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the user and server is intended to be an + alternating dialogue. As such, the user issues an FTP command and + the server responds with a prompt primary reply. The user should + wait for this initial primary success or failure response before + sending further commands. + + Certain commands require a second reply for which the user should + also wait. These replies may, for example, report on the progress + or completion of file transfer or the closing of the data + connection. They are secondary replies to file transfer commands. + + One important group of informational replies is the connection + greetings. Under normal circumstances, a server will send a 220 + reply, "awaiting input", when the connection is completed. The + user should wait for this greeting message before sending any + commands. If the server is unable to accept input right away, a + 120 "expected delay" reply should be sent immediately and a 220 + reply when ready. The user will then know not to hang up if there + is a delay. + + Spontaneous Replies + + Sometimes "the system" spontaneously has a message to be sent + to a user (usually all users). For example, "System going down + in 15 minutes". There is no provision in FTP for such + spontaneous information to be sent from the server to the user. + It is recommended that such information be queued in the + server-PI and delivered to the user-PI in the next reply + (possibly making it a multi-line reply). + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a server may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + Command-Reply Sequences + + In this section, the command-reply sequence is presented. Each + command is listed with its possible replies; command groups are + listed together. Preliminary replies are listed first (with + their succeeding replies indented and under them), then + positive and negative completion, and finally intermediary + + + + +Postel & Reynolds [Page 49] + + + +RFC 959 October 1985 +File Transfer Protocol + + + replies with the remaining commands from the sequence + following. This listing forms the basis for the state + diagrams, which will be presented separately. + + Connection Establishment + 120 + 220 + 220 + 421 + Login + USER + 230 + 530 + 500, 501, 421 + 331, 332 + PASS + 230 + 202 + 530 + 500, 501, 503, 421 + 332 + ACCT + 230 + 202 + 530 + 500, 501, 503, 421 + CWD + 250 + 500, 501, 502, 421, 530, 550 + CDUP + 200 + 500, 501, 502, 421, 530, 550 + SMNT + 202, 250 + 500, 501, 502, 421, 530, 550 + Logout + REIN + 120 + 220 + 220 + 421 + 500, 502 + QUIT + 221 + 500 + + + + +Postel & Reynolds [Page 50] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Transfer parameters + PORT + 200 + 500, 501, 421, 530 + PASV + 227 + 500, 501, 502, 421, 530 + MODE + 200 + 500, 501, 504, 421, 530 + TYPE + 200 + 500, 501, 504, 421, 530 + STRU + 200 + 500, 501, 504, 421, 530 + File action commands + ALLO + 200 + 202 + 500, 501, 504, 421, 530 + REST + 500, 501, 502, 421, 530 + 350 + STOR + 125, 150 + (110) + 226, 250 + 425, 426, 451, 551, 552 + 532, 450, 452, 553 + 500, 501, 421, 530 + STOU + 125, 150 + (110) + 226, 250 + 425, 426, 451, 551, 552 + 532, 450, 452, 553 + 500, 501, 421, 530 + RETR + 125, 150 + (110) + 226, 250 + 425, 426, 451 + 450, 550 + 500, 501, 421, 530 + + + + +Postel & Reynolds [Page 51] + + + +RFC 959 October 1985 +File Transfer Protocol + + + LIST + 125, 150 + 226, 250 + 425, 426, 451 + 450 + 500, 501, 502, 421, 530 + NLST + 125, 150 + 226, 250 + 425, 426, 451 + 450 + 500, 501, 502, 421, 530 + APPE + 125, 150 + (110) + 226, 250 + 425, 426, 451, 551, 552 + 532, 450, 550, 452, 553 + 500, 501, 502, 421, 530 + RNFR + 450, 550 + 500, 501, 502, 421, 530 + 350 + RNTO + 250 + 532, 553 + 500, 501, 502, 503, 421, 530 + DELE + 250 + 450, 550 + 500, 501, 502, 421, 530 + RMD + 250 + 500, 501, 502, 421, 530, 550 + MKD + 257 + 500, 501, 502, 421, 530, 550 + PWD + 257 + 500, 501, 502, 421, 550 + ABOR + 225, 226 + 500, 501, 502, 421 + + + + + + +Postel & Reynolds [Page 52] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Informational commands + SYST + 215 + 500, 501, 502, 421 + STAT + 211, 212, 213 + 450 + 500, 501, 502, 421, 530 + HELP + 211, 214 + 500, 501, 502, 421 + Miscellaneous commands + SITE + 200 + 202 + 500, 501, 530 + NOOP + 200 + 500 421 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 53] + + + +RFC 959 October 1985 +File Transfer Protocol + + +6. STATE DIAGRAMS + + Here we present state diagrams for a very simple minded FTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of FTP commands or command + sequences. + + The command groupings were determined by constructing a model for + each command then collecting together the commands with structurally + identical models. + + For each command or command sequence there are three possible + outcomes: success (S), failure (F), and error (E). In the state + diagrams below we use the symbol B for "begin", and the symbol W for + "wait for reply". + + We first present the diagram that represents the largest group of FTP + commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + ABOR, ALLO, DELE, CWD, CDUP, SMNT, HELP, MODE, NOOP, PASV, + QUIT, SITE, PORT, SYST, STAT, RMD, MKD, PWD, STRU, and TYPE. + + + + + + + + + + + + +Postel & Reynolds [Page 54] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The other large group of commands is represented by a very similar + diagram: + + + 3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ --->+---+ +---+ + | | | + | | | 4,5 +---+ + | 1 | ----------->| F | + ----- +---+ + + + This diagram models the commands: + + APPE, LIST, NLST, REIN, RETR, STOR, and STOU. + + Note that this second model could also be used to represent the first + group of commands, the only difference being that in the first group + the 100 series replies are unexpected and therefore treated as error, + while the second group expects (some may require) 100 series replies. + Remember that at most, one 100 series reply is allowed per command. + + The remaining diagrams model command sequences, perhaps the simplest + of these is the rename sequence: + + + +---+ RNFR +---+ 1,2 +---+ + | B |---------->| W |---------->| E | + +---+ +---+ -->+---+ + | | | + 3 | | 4,5 | + -------------- ------ | + | | | +---+ + | ------------->| S | + | | 1,3 | | +---+ + | 2| -------- + | | | | + V | | | + +---+ RNTO +---+ 4,5 ----->+---+ + | |---------->| W |---------->| F | + +---+ +---+ +---+ + + + +Postel & Reynolds [Page 55] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The next diagram is a simple model of the Restart command: + + + +---+ REST +---+ 1,2 +---+ + | B |---------->| W |---------->| E | + +---+ +---+ -->+---+ + | | | + 3 | | 4,5 | + -------------- ------ | + | | | +---+ + | ------------->| S | + | | 3 | | +---+ + | 2| -------- + | | | | + V | | | + +---+ cmd +---+ 4,5 ----->+---+ + | |---------->| W |---------->| F | + +---+ -->+---+ +---+ + | | + | 1 | + ------ + + + Where "cmd" is APPE, STOR, or RETR. + + We note that the above three models are similar. The Restart differs + from the Rename two only in the treatment of 100 series replies at + the second stage, while the second group expects (some may require) + 100 series replies. Remember that at most, one 100 series reply is + allowed per command. + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 56] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The most complicated diagram is for the Login sequence: + + + 1 + +---+ USER +---+------------->+---+ + | B |---------->| W | 2 ---->| E | + +---+ +---+------ | -->+---+ + | | | | | + 3 | | 4,5 | | | + -------------- ----- | | | + | | | | | + | | | | | + | --------- | + | 1| | | | + V | | | | + +---+ PASS +---+ 2 | ------>+---+ + | |---------->| W |------------->| S | + +---+ +---+ ---------->+---+ + | | | | | + 3 | |4,5| | | + -------------- -------- | + | | | | | + | | | | | + | ----------- + | 1,3| | | | + V | 2| | | + +---+ ACCT +---+-- | ----->+---+ + | |---------->| W | 4,5 -------->| F | + +---+ +---+------------->+---+ + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 57] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Finally, we present a generalized diagram that could be used to model + the command and reply interchange: + + + ------------------------------------ + | | + Begin | | + | V | + | +---+ cmd +---+ 2 +---+ | + -->| |------->| |---------->| | | + | | | W | | S |-----| + -->| | -->| |----- | | | + | +---+ | +---+ 4,5 | +---+ | + | | | | | | | + | | | 1| |3 | +---+ | + | | | | | | | | | + | | ---- | ---->| F |----- + | | | | | + | | | +---+ + ------------------- + | + | + V + End + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 58] + + + +RFC 959 October 1985 +File Transfer Protocol + + +7. TYPICAL FTP SCENARIO + + User at host U wanting to transfer files to/from host S: + + In general, the user will communicate to the server via a mediating + user-FTP process. The following may be a typical scenario. The + user-FTP prompts are shown in parentheses, '---->' represents + commands from host U to host S, and '<----' represents replies from + host S to host U. + + LOCAL COMMANDS BY USER ACTION INVOLVED + + ftp (host) multics Connect to host S, port L, + establishing control connections. + <---- 220 Service ready . + username Doe USER Doe----> + <---- 331 User name ok, + need password. + password mumble PASS mumble----> + <---- 230 User logged in. + retrieve (local type) ASCII + (local pathname) test 1 User-FTP opens local file in ASCII. + (for. pathname) test.pl1 RETR test.pl1 ----> + <---- 150 File status okay; + about to open data + connection. + Server makes data connection + to port U. + + <---- 226 Closing data connection, + file transfer successful. + type Image TYPE I ----> + <---- 200 Command OK + store (local type) image + (local pathname) file dump User-FTP opens local file in Image. + (for.pathname) >udd>cn>fd STOR >udd>cn>fd ----> + <---- 550 Access denied + terminate QUIT ----> + Server closes all + connections. + +8. CONNECTION ESTABLISHMENT + + The FTP control connection is established via TCP between the user + process port U and the server process port L. This protocol is + assigned the service port 21 (25 octal), that is L=21. + + + +Postel & Reynolds [Page 59] + + + +RFC 959 October 1985 +File Transfer Protocol + + +APPENDIX I - PAGE STRUCTURE + + The need for FTP to support page structure derives principally from + the need to support efficient transmission of files between TOPS-20 + systems, particularly the files used by NLS. + + The file system of TOPS-20 is based on the concept of pages. The + operating system is most efficient at manipulating files as pages. + The operating system provides an interface to the file system so that + many applications view files as sequential streams of characters. + However, a few applications use the underlying page structures + directly, and some of these create holey files. + + A TOPS-20 disk file consists of four things: a pathname, a page + table, a (possibly empty) set of pages, and a set of attributes. + + The pathname is specified in the RETR or STOR command. It includes + the directory name, file name, file name extension, and generation + number. + + The page table contains up to 2**18 entries. Each entry may be + EMPTY, or may point to a page. If it is not empty, there are also + some page-specific access bits; not all pages of a file need have the + same access protection. + + A page is a contiguous set of 512 words of 36 bits each. + + The attributes of the file, in the File Descriptor Block (FDB), + contain such things as creation time, write time, read time, writer's + byte-size, end-of-file pointer, count of reads and writes, backup + system tape numbers, etc. + + Note that there is NO requirement that entries in the page table be + contiguous. There may be empty page table slots between occupied + ones. Also, the end of file pointer is simply a number. There is no + requirement that it in fact point at the "last" datum in the file. + Ordinary sequential I/O calls in TOPS-20 will cause the end of file + pointer to be left after the last datum written, but other operations + may cause it not to be so, if a particular programming system so + requires. + + In fact, in both of these special cases, "holey" files and + end-of-file pointers NOT at the end of the file, occur with NLS data + files. + + + + + +Postel & Reynolds [Page 60] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The TOPS-20 paged files can be sent with the FTP transfer parameters: + TYPE L 36, STRU P, and MODE S (in fact, any mode could be used). + + Each page of information has a header. Each header field, which is a + logical byte, is a TOPS-20 word, since the TYPE is L 36. + + The header fields are: + + Word 0: Header Length. + + The header length is 5. + + Word 1: Page Index. + + If the data is a disk file page, this is the number of that + page in the file's page map. Empty pages (holes) in the file + are simply not sent. Note that a hole is NOT the same as a + page of zeros. + + Word 2: Data Length. + + The number of data words in this page, following the header. + Thus, the total length of the transmission unit is the Header + Length plus the Data Length. + + Word 3: Page Type. + + A code for what type of chunk this is. A data page is type 3, + the FDB page is type 2. + + Word 4: Page Access Control. + + The access bits associated with the page in the file's page + map. (This full word quantity is put into AC2 of an SPACS by + the program reading from net to disk.) + + After the header are Data Length data words. Data Length is + currently either 512 for a data page or 31 for an FDB. Trailing + zeros in a disk file page may be discarded, making Data Length less + than 512 in that case. + + + + + + + + + +Postel & Reynolds [Page 61] + + + +RFC 959 October 1985 +File Transfer Protocol + + +APPENDIX II - DIRECTORY COMMANDS + + Since UNIX has a tree-like directory structure in which directories + are as easy to manipulate as ordinary files, it is useful to expand + the FTP servers on these machines to include commands which deal with + the creation of directories. Since there are other hosts on the + ARPA-Internet which have tree-like directories (including TOPS-20 and + Multics), these commands are as general as possible. + + Four directory commands have been added to FTP: + + MKD pathname + + Make a directory with the name "pathname". + + RMD pathname + + Remove the directory with the name "pathname". + + PWD + + Print the current working directory name. + + CDUP + + Change to the parent of the current working directory. + + The "pathname" argument should be created (removed) as a + subdirectory of the current working directory, unless the "pathname" + string contains sufficient information to specify otherwise to the + server, e.g., "pathname" is an absolute pathname (in UNIX and + Multics), or pathname is something like "" to + TOPS-20. + + REPLY CODES + + The CDUP command is a special case of CWD, and is included to + simplify the implementation of programs for transferring directory + trees between operating systems having different syntaxes for + naming the parent directory. The reply codes for CDUP be + identical to the reply codes of CWD. + + The reply codes for RMD be identical to the reply codes for its + file analogue, DELE. + + The reply codes for MKD, however, are a bit more complicated. A + freshly created directory will probably be the object of a future + + +Postel & Reynolds [Page 62] + + + +RFC 959 October 1985 +File Transfer Protocol + + + CWD command. Unfortunately, the argument to MKD may not always be + a suitable argument for CWD. This is the case, for example, when + a TOPS-20 subdirectory is created by giving just the subdirectory + name. That is, with a TOPS-20 server FTP, the command sequence + + MKD MYDIR + CWD MYDIR + + will fail. The new directory may only be referred to by its + "absolute" name; e.g., if the MKD command above were issued while + connected to the directory , the new subdirectory + could only be referred to by the name . + + Even on UNIX and Multics, however, the argument given to MKD may + not be suitable. If it is a "relative" pathname (i.e., a pathname + which is interpreted relative to the current directory), the user + would need to be in the same current directory in order to reach + the subdirectory. Depending on the application, this may be + inconvenient. It is not very robust in any case. + + To solve these problems, upon successful completion of an MKD + command, the server should return a line of the form: + + 257"" + + That is, the server will tell the user what string to use when + referring to the created directory. The directory name can + contain any character; embedded double-quotes should be escaped by + double-quotes (the "quote-doubling" convention). + + For example, a user connects to the directory /usr/dm, and creates + a subdirectory, named pathname: + + CWD /usr/dm + 200 directory changed to /usr/dm + MKD pathname + 257 "/usr/dm/pathname" directory created + + An example with an embedded double quote: + + MKD foo"bar + 257 "/usr/dm/foo""bar" directory created + CWD /usr/dm/foo"bar + 200 directory changed to /usr/dm/foo"bar + + + + + +Postel & Reynolds [Page 63] + + + +RFC 959 October 1985 +File Transfer Protocol + + + The prior existence of a subdirectory with the same name is an + error, and the server must return an "access denied" error reply + in that case. + + CWD /usr/dm + 200 directory changed to /usr/dm + MKD pathname + 521-"/usr/dm/pathname" directory already exists; + 521 taking no action. + + The failure replies for MKD are analogous to its file creating + cousin, STOR. Also, an "access denied" return is given if a file + name with the same name as the subdirectory will conflict with the + creation of the subdirectory (this is a problem on UNIX, but + shouldn't be one on TOPS-20). + + Essentially because the PWD command returns the same type of + information as the successful MKD command, the successful PWD + command uses the 257 reply code as well. + + SUBTLETIES + + Because these commands will be most useful in transferring + subtrees from one machine to another, carefully observe that the + argument to MKD is to be interpreted as a sub-directory of the + current working directory, unless it contains enough information + for the destination host to tell otherwise. A hypothetical + example of its use in the TOPS-20 world: + + CWD + 200 Working directory changed + MKD overrainbow + 257 "" directory created + CWD overrainbow + 431 No such directory + CWD + 200 Working directory changed + + CWD + 200 Working directory changed to + MKD + 257 "" directory created + CWD + + Note that the first example results in a subdirectory of the + connected directory. In contrast, the argument in the second + example contains enough information for TOPS-20 to tell that the + + +Postel & Reynolds [Page 64] + + + +RFC 959 October 1985 +File Transfer Protocol + + + directory is a top-level directory. Note also that + in the first example the user "violated" the protocol by + attempting to access the freshly created directory with a name + other than the one returned by TOPS-20. Problems could have + resulted in this case had there been an directory; + this is an ambiguity inherent in some TOPS-20 implementations. + Similar considerations apply to the RMD command. The point is + this: except where to do so would violate a host's conventions for + denoting relative versus absolute pathnames, the host should treat + the operands of the MKD and RMD commands as subdirectories. The + 257 reply to the MKD command must always contain the absolute + pathname of the created directory. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 65] + + + +RFC 959 October 1985 +File Transfer Protocol + + +APPENDIX III - RFCs on FTP + + Bhushan, Abhay, "A File Transfer Protocol", RFC 114 (NIC 5823), + MIT-Project MAC, 16 April 1971. + + Harslem, Eric, and John Heafner, "Comments on RFC 114 (A File + Transfer Protocol)", RFC 141 (NIC 6726), RAND, 29 April 1971. + + Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 172 + (NIC 6794), MIT-Project MAC, 23 June 1971. + + Braden, Bob, "Comments on DTP and FTP Proposals", RFC 238 (NIC 7663), + UCLA/CCN, 29 September 1971. + + Bhushan, Abhay, et al, "The File Transfer Protocol", RFC 265 + (NIC 7813), MIT-Project MAC, 17 November 1971. + + McKenzie, Alex, "A Suggested Addition to File Transfer Protocol", + RFC 281 (NIC 8163), BBN, 8 December 1971. + + Bhushan, Abhay, "The Use of "Set Data Type" Transaction in File + Transfer Protocol", RFC 294 (NIC 8304), MIT-Project MAC, + 25 January 1972. + + Bhushan, Abhay, "The File Transfer Protocol", RFC 354 (NIC 10596), + MIT-Project MAC, 8 July 1972. + + Bhushan, Abhay, "Comments on the File Transfer Protocol (RFC 354)", + RFC 385 (NIC 11357), MIT-Project MAC, 18 August 1972. + + Hicks, Greg, "User FTP Documentation", RFC 412 (NIC 12404), Utah, + 27 November 1972. + + Bhushan, Abhay, "File Transfer Protocol (FTP) Status and Further + Comments", RFC 414 (NIC 12406), MIT-Project MAC, 20 November 1972. + + Braden, Bob, "Comments on File Transfer Protocol", RFC 430 + (NIC 13299), UCLA/CCN, 7 February 1973. + + Thomas, Bob, and Bob Clements, "FTP Server-Server Interaction", + RFC 438 (NIC 13770), BBN, 15 January 1973. + + Braden, Bob, "Print Files in FTP", RFC 448 (NIC 13299), UCLA/CCN, + 27 February 1973. + + McKenzie, Alex, "File Transfer Protocol", RFC 454 (NIC 14333), BBN, + 16 February 1973. + + +Postel & Reynolds [Page 66] + + + +RFC 959 October 1985 +File Transfer Protocol + + + Bressler, Bob, and Bob Thomas, "Mail Retrieval via FTP", RFC 458 + (NIC 14378), BBN-NET and BBN-TENEX, 20 February 1973. + + Neigus, Nancy, "File Transfer Protocol", RFC 542 (NIC 17759), BBN, + 12 July 1973. + + Krilanovich, Mark, and George Gregg, "Comments on the File Transfer + Protocol", RFC 607 (NIC 21255), UCSB, 7 January 1974. + + Pogran, Ken, and Nancy Neigus, "Response to RFC 607 - Comments on the + File Transfer Protocol", RFC 614 (NIC 21530), BBN, 28 January 1974. + + Krilanovich, Mark, George Gregg, Wayne Hathaway, and Jim White, + "Comments on the File Transfer Protocol", RFC 624 (NIC 22054), UCSB, + Ames Research Center, SRI-ARC, 28 February 1974. + + Bhushan, Abhay, "FTP Comments and Response to RFC 430", RFC 463 + (NIC 14573), MIT-DMCG, 21 February 1973. + + Braden, Bob, "FTP Data Compression", RFC 468 (NIC 14742), UCLA/CCN, + 8 March 1973. + + Bhushan, Abhay, "FTP and Network Mail System", RFC 475 (NIC 14919), + MIT-DMCG, 6 March 1973. + + Bressler, Bob, and Bob Thomas "FTP Server-Server Interaction - II", + RFC 478 (NIC 14947), BBN-NET and BBN-TENEX, 26 March 1973. + + White, Jim, "Use of FTP by the NIC Journal", RFC 479 (NIC 14948), + SRI-ARC, 8 March 1973. + + White, Jim, "Host-Dependent FTP Parameters", RFC 480 (NIC 14949), + SRI-ARC, 8 March 1973. + + Padlipsky, Mike, "An FTP Command-Naming Problem", RFC 506 + (NIC 16157), MIT-Multics, 26 June 1973. + + Day, John, "Memo to FTP Group (Proposal for File Access Protocol)", + RFC 520 (NIC 16819), Illinois, 25 June 1973. + + Merryman, Robert, "The UCSD-CC Server-FTP Facility", RFC 532 + (NIC 17451), UCSD-CC, 22 June 1973. + + Braden, Bob, "TENEX FTP Problem", RFC 571 (NIC 18974), UCLA/CCN, + 15 November 1973. + + + + +Postel & Reynolds [Page 67] + + + +RFC 959 October 1985 +File Transfer Protocol + + + McKenzie, Alex, and Jon Postel, "Telnet and FTP Implementation - + Schedule Change", RFC 593 (NIC 20615), BBN and MITRE, + 29 November 1973. + + Sussman, Julie, "FTP Error Code Usage for More Reliable Mail + Service", RFC 630 (NIC 30237), BBN, 10 April 1974. + + Postel, Jon, "Revised FTP Reply Codes", RFC 640 (NIC 30843), + UCLA/NMC, 5 June 1974. + + Harvey, Brian, "Leaving Well Enough Alone", RFC 686 (NIC 32481), + SU-AI, 10 May 1975. + + Harvey, Brian, "One More Try on the FTP", RFC 691 (NIC 32700), SU-AI, + 28 May 1975. + + Lieb, J., "CWD Command of FTP", RFC 697 (NIC 32963), 14 July 1975. + + Harrenstien, Ken, "FTP Extension: XSEN", RFC 737 (NIC 42217), SRI-KL, + 31 October 1977. + + Harrenstien, Ken, "FTP Extension: XRSQ/XRCP", RFC 743 (NIC 42758), + SRI-KL, 30 December 1977. + + Lebling, P. David, "Survey of FTP Mail and MLFL", RFC 751, MIT, + 10 December 1978. + + Postel, Jon, "File Transfer Protocol Specification", RFC 765, ISI, + June 1980. + + Mankins, David, Dan Franklin, and Buzz Owen, "Directory Oriented FTP + Commands", RFC 776, BBN, December 1980. + + Padlipsky, Michael, "FTP Unique-Named Store Command", RFC 949, MITRE, + July 1985. + + + + + + + + + + + + + + +Postel & Reynolds [Page 68] + + + +RFC 959 October 1985 +File Transfer Protocol + + +REFERENCES + + [1] Feinler, Elizabeth, "Internet Protocol Transition Workbook", + Network Information Center, SRI International, March 1982. + + [2] Postel, Jon, "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, DARPA, September 1981. + + [3] Postel, Jon, and Joyce Reynolds, "Telnet Protocol + Specification", RFC 854, ISI, May 1983. + + [4] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC 943, + ISI, April 1985. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel & Reynolds [Page 69] + diff --git a/deps/ftplib-4.0-1/additional_rfcs b/deps/ftplib-4.0-1/additional_rfcs new file mode 100644 index 0000000..fd73fff --- /dev/null +++ b/deps/ftplib-4.0-1/additional_rfcs @@ -0,0 +1,2 @@ +RFC2228 FTP Security Extensions. M. Horowitz, S. Lunt. October 1997. +RFC1579 Firewall-Friendly FTP. S. Bellovin. February 1994. diff --git a/deps/ftplib-4.0-1/html/FtpAccess.html b/deps/ftplib-4.0-1/html/FtpAccess.html new file mode 100644 index 0000000..3ce3127 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpAccess.html @@ -0,0 +1,42 @@ + + + +FtpAccess + + + +

FtpAccess

+

Open a file or directory on the remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpAccess(const char *path, int typ, int mode, netbuf *nControl,
+    netbuf **nData);
+
+

PARAMETERS

+
+
path
+
Specifies the name of the remote file or directory to +open.
+
typ
+
Specifies the type of transfer to be performed. FTPLIB_DIR +performs a terse directory. FTPLIB_DIR_VERBOSE performs a verbose +directory. FTPLIB_FILE_READ opens a remote file for reading. +FTPLIB_FILE_WRITE creates a remote file and readies it for +writing.
+
mode
+
Specifies the transfer mode as FTPLIB_ASCII or +FTPLIB_IMAGE.
+
nControl
+
A handle returned by FtpConnect().
+
nData
+
Specifies the address to store a pointer to the created data +handle.
+
+

DESCRIPTION

+

FtpAccess() opens a remote file or directory and returns a +handle for the calling program to use to transfer data.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpCDUp.html b/deps/ftplib-4.0-1/html/FtpCDUp.html new file mode 100644 index 0000000..4224590 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpCDUp.html @@ -0,0 +1,26 @@ + + + +FtpCDUp + + + +

FtpCDUp

+

Change to parent directory.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpCDUp(netbuf *nControl);
+
+

PARAMETERS

+
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpCDUp() sends a CDUP command to the remote server.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpChdir.html b/deps/ftplib-4.0-1/html/FtpChdir.html new file mode 100644 index 0000000..e033910 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpChdir.html @@ -0,0 +1,28 @@ + + + +FtpChdir + + + +

FtpChdir

+

Change working directory on server.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpChdir(const char *path, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
Specifies the desired working directory on the server.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

Sends a change working directory request to the server using the +specified path.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpClearCallback.html b/deps/ftplib-4.0-1/html/FtpClearCallback.html new file mode 100644 index 0000000..61b0c56 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpClearCallback.html @@ -0,0 +1,27 @@ + + + +FtpClearCallback + + + +

FtpClearCallback

+

Clears callback settings.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpClearCallback(netbuf *nControl);
+
+

PARAMETERS

+
+
nControl
+
A handle returned by FtpConnect() +or FtpAccess().
+
+

DESCRIPTION

+

FtpClearCallback() clears all callback options on a connection.

+

RETURN VALUE

+

Returns 1 if a valid option was specified and the value is +legal. Otherwise, returns 0.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpClose.html b/deps/ftplib-4.0-1/html/FtpClose.html new file mode 100644 index 0000000..c2f7565 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpClose.html @@ -0,0 +1,32 @@ + + + +FtpClose + + + +

FtpClose

+

Close a connection.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpClose(netbuf *nData);
+
+

PARAMETERS

+
+
nData
+
A handle returned by FtpAccess() +or FtpConnect().
+
+

DESCRIPTION

+

Closes the connection specified by 'nData' and frees associated +resources. If the connection is a command connection, any +associated data connection is also closed and the command +connection is closed without sending any commands.

+

FtpClose() destroys the connection object and any associated +data connection object. Do not use either connection after calling +FtpClose().

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpConnect.html b/deps/ftplib-4.0-1/html/FtpConnect.html new file mode 100644 index 0000000..f590a8a --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpConnect.html @@ -0,0 +1,35 @@ + + + +FtpConnect + + + +

FtpConnect

+

Connect to an FTP server.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpConnect(const char *host, netbuf **nControl);
+
+

PARAMETERS

+
+
host
+
The name of the host machine to connect to and optionally an +alternate port number to use.
+
nControl
+
The address where the pointer to the newly created control +handle should be stored.
+
+

DESCRIPTION

+

FtpConnect() establishes a connection to the FTP server on the +specified machine and returns a handle which can be used to +initiate data transfers. The host name should be specified as +<host> or <host>:<port>. <host> may be +either a host name or ip address. <port> may be either a +service name or a port number.

+

RETURN VALUE

+

If the connection to the remote server if successful, +FtpConnect() returns 1. Otherwise, 0 is returned.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpDelete.html b/deps/ftplib-4.0-1/html/FtpDelete.html new file mode 100644 index 0000000..03a14a9 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpDelete.html @@ -0,0 +1,28 @@ + + + +FtpDelete + + + +

FtpDelete

+

Removes a file from the remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpDelete(const char *fnm, netbuf *nControl);
+
+

PARAMETERS

+
+
fnm
+
The name of the file which is to be removed.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

Requests that the server remove the specified file from the +remote file system.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpDir.html b/deps/ftplib-4.0-1/html/FtpDir.html new file mode 100644 index 0000000..bccccc5 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpDir.html @@ -0,0 +1,37 @@ + + + +FtpDir + + + +

FtpDir

+

Retrieves a verbose directory listing.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpDir(const char *outputfile, const char *path, netbuf *nControl);
+
+

PARAMETERS

+
+
outputfile
+
Name of a local file to receive the directory listing. If +specified as NULL, the directory listing is written to stdout.
+
path
+
File specification to pass to remote 'ls'.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

Sends a LIST command to the server with the specified path. The +response to this is usually a long format directory listing which +will be written to the file named in outputfile. If outputfile is +specified as NULL, the list will be written to stdout.

+

The format of the listing is dependent on the type of the remote +system. The system type can be determined from +FtpSysType().

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpGet.html b/deps/ftplib-4.0-1/html/FtpGet.html new file mode 100644 index 0000000..6664ec1 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpGet.html @@ -0,0 +1,34 @@ + + + +FtpGet + + + +

FtpGet

+

Retreive a file from the remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpGet(const char *output, const char *path, char mode, netbuf *nControl);
+
+

PARAMETERS

+
+
output
+
Name of a local file to receive the contents of the remote +file. If specified as NULL file data will be written to stdout.
+
path
+
Name of remote file to be retrieved.
+
mode
+
Specifies the transfer mode as FTPLIB_ASCII or +FTPLIB_IMAGE.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpGet() copies the contents of a remote file to a local +file.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpInit.html b/deps/ftplib-4.0-1/html/FtpInit.html new file mode 100644 index 0000000..6af86c8 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpInit.html @@ -0,0 +1,22 @@ + + + +FtpInit + + + +

FtpInit

+

Initialize the library.

+

SYNOPSIS

+
+#include <ftplib.h>
+void FtpInit(void);
+
+

PARAMETERS

+

None.

+

DESCRIPTION

+

Performs any required initialization for the library.

+

RETURN VALUE

+

None.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpLastResponse.html b/deps/ftplib-4.0-1/html/FtpLastResponse.html new file mode 100644 index 0000000..24c6512 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpLastResponse.html @@ -0,0 +1,31 @@ + + + +FtpLastResponse + + + +

FtpLastResponse

+

Retrieve the last response sent by the server.

+

SYNOPSIS

+
+#include <ftplib.h>
+char *FtpLastResponse(netbuf *nControl);
+
+

PARAMETERS

+
+
nControl
+
A pointer to a control handle returned by +FtpConnect().
+
+

DESCRIPTION

+

FtpLastResponse() returns a pointer to the last response string +sent by the server. This can be parsed by the user program to +determine more information about the last request or can be +displayed along with an error message.

+

RETURN VALUE

+

If nControl is a valid control handle, FtpLastResponse() returns +a pointer to the last server response string. Otherwise, NULL is +returned.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpLogin.html b/deps/ftplib-4.0-1/html/FtpLogin.html new file mode 100644 index 0000000..cff609e --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpLogin.html @@ -0,0 +1,30 @@ + + + +FtpLogin + + + +

FtpLogin

+

Login to remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpLogin(const char *user, const char *pass, netbuf *nControl);
+
+

PARAMETERS

+
+
user
+
Specifies the username.
+
pass
+
Specifies the password.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpLogin() attempts to login to the remote system with the +supplied username and password.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpMkdir.html b/deps/ftplib-4.0-1/html/FtpMkdir.html new file mode 100644 index 0000000..cd3a9c6 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpMkdir.html @@ -0,0 +1,28 @@ + + + +FtpMkdir + + + +

FtpMkdir

+

Create a directory on the remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpMkdir(const char *path, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
Specifies the argument to mkdir on the remote system.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpMkdir() sends a make directory request to the remote +system.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpModDate.html b/deps/ftplib-4.0-1/html/FtpModDate.html new file mode 100644 index 0000000..34af4d9 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpModDate.html @@ -0,0 +1,36 @@ + + + +FtpModDate + + + +

FtpModDate

+

Determine last modification time of a remote file.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpModDate(char *path, char *buf, int max, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
Name of remote file to be checked.
+
buf
+
A pointer to a buffer where the result should be returned.
+
max
+
Specifies the size of the user's buffer.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpModDate() attempts to determine the last access time of a +remote file and return it to the user's buffer. The date and time +are returned as a string in the format 'YYYYMMDDHHMMSS'.

+

RETURN VALUE

+

If a good response is received and the date and time are +successfully parsed out of the result, 1 is returned. Otherwise, 0 +is returned.

+

Some servers may not support the MDTM command.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpNlst.html b/deps/ftplib-4.0-1/html/FtpNlst.html new file mode 100644 index 0000000..88b87c8 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpNlst.html @@ -0,0 +1,33 @@ + + + +FtpNlst + + + +

FtpNlst

+

Retrieves a terse directory listing.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpNlst(const char *output, const char *path, netbuf *nControl);
+
+

PARAMETERS

+
+
output
+
Specifies the name of a file to receive the directory listing. If +specified as NULL the directory listing will be written to +stdout.
+
path
+
Specifies an argument to 'ls' on the remote system.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

Performs a short form directory listing of the specified path on +the remote system. The results are written to the specified +file.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpOptions.html b/deps/ftplib-4.0-1/html/FtpOptions.html new file mode 100644 index 0000000..da22c7b --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpOptions.html @@ -0,0 +1,63 @@ + + + +FtpOptions + + + +

FtpOptions

+

Set connection options.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpOptions(int opt, long val, netbuf *nControl);
+
+

PARAMETERS

+
+
opt
+
Specifies the option to change. Valid options are +FTPLIB_CONNMODE, FTPLIB_CALLBACK, FTPLIB_IDLETIME, +FTPLIB_CALLBACKARG, and FTPLIB_CALLBACKBYTES.
+
val
+
Specifies the new value for the option. The value may need to +by cast to a long.
+
nControl
+
A handle returned by FtpConnect() +or FtpAccess().
+
+

DESCRIPTION

+

FtpOptions() changes the options for a connection handle. A data +connection inherits the options assigned to the control connection +it is created from. Callbacks are only called on file data +connections.

+

New programs should +call FtpSetCallback() +and FtpClearCallback() to change +callback options.

+

The following options and values are recognized.

+
+
FTPLIB_CONNMODE
+
Specifies the connection mode. Either FTPLIB_PASSIVE or +FTPLIB_PORT.
+
FTPLIB_CALLBACK (deprecated)
+
Specifies the address of a user callback routine.
+
FTPLIB_IDLETIME (deprecated)
+
Specifies the socket idle time in milliseconds that triggers +calling the user's callback routine.
+
FTPLIB_CALLBACKARG (deprecated)
+
Specifies an argument to pass to the user's callback +routine.
+
FTPLIB_CALLBACKBYTES (deprecated)
+
Specifies the number of bytes to transfer between calls to the +user's callback routine.
+
+

The connection mode tells ftplib if it should use PASV or PORT +to establish data connections. The default is specified as a build +option.

+

See FtpSetCallback() for a +description of using callbacks.

+

RETURN VALUE

+

Returns 1 if a valid option was specified and the value is +legal. Otherwise, returns 0.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpPut.html b/deps/ftplib-4.0-1/html/FtpPut.html new file mode 100644 index 0000000..a3a7e69 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpPut.html @@ -0,0 +1,34 @@ + + + +FtpPut + + + +

FtpPut

+

Send a file to the remote system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpPut(const char *input, const char *path, char mode, netbuf *nControl);
+
+

PARAMETERS

+
+
input
+
Specifies the name of a local file to be transfered to the +server. If specified as NULL file data will be read from stdin.
+
path
+
Specifies the name to be given to the file on the remote +system.
+
mode
+
Specifies the transfer mode as FTPLIB_ASCII or +FTPLIB_IMAGE.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpPut() transfers a local file to the remote system.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpPwd.html b/deps/ftplib-4.0-1/html/FtpPwd.html new file mode 100644 index 0000000..8ac927b --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpPwd.html @@ -0,0 +1,30 @@ + + + +FtpPwd + + + +

FtpPwd

+

Determine current working directory on server.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpPwd(char *path, int max, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
A pointer to a buffer where the result should be returned.
+
max
+
Specifies the size of the user's buffer.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpPwd() attempts to determine the current default directory at +the server and return it to the user's buffer.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpQuit.html b/deps/ftplib-4.0-1/html/FtpQuit.html new file mode 100644 index 0000000..32b2485 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpQuit.html @@ -0,0 +1,28 @@ + + + +FtpQuit + + + +

FtpQuit

+

Sends a QUIT command and closes the connection to the server.

+

SYNOPSIS

+
+#include <ftplib.h>
+void FtpQuit(netbuf *nControl);
+
+

PARAMETERS

+
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpQuit() sends a QUIT command to the server and waits for a +response. It closes the connection to the remote server and frees any +resources associated with the connection. The connection should not +be used after calling FtpQuit().

+

RETURN VALUE

+

None.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpRead.html b/deps/ftplib-4.0-1/html/FtpRead.html new file mode 100644 index 0000000..fa7519d --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpRead.html @@ -0,0 +1,34 @@ + + + +FtpRead + + + +

FtpRead

+

Read data from a remote file or directory.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpRead(void *buf, int max, netbuf *nData);
+
+

PARAMETERS

+
+
buf
+
Specifies the address of a buffer where received data will be +written.
+
max
+
Specifies the size of the user's buffer.
+
nData
+
A handle returned by FtpAccess().
+
+

DESCRIPTION

+

FtpRead copies up to max bytes of data from the specified data +connection and returns it to the user's buffer. If the data +connection was opened in ascii mode, no more than one line of data +will be returned.

+

RETURN VALUE

+

Returns the number of bytes written to the user's buffer or -1 +on error or end of file.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpRename.html b/deps/ftplib-4.0-1/html/FtpRename.html new file mode 100644 index 0000000..d91c9d6 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpRename.html @@ -0,0 +1,30 @@ + + + +FtpRename + + + +

FtpRename

+

Rename a remote file.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpRename(const char *src, const char *dst, netbuf *nControl);
+
+

PARAMETERS

+
+
src
+
A string containing the current name of the remote file.
+
dst
+
A string containing the desired new name for the remote +file.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpRename() sends a rename request to the remote server.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpRmdir.html b/deps/ftplib-4.0-1/html/FtpRmdir.html new file mode 100644 index 0000000..a81badf --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpRmdir.html @@ -0,0 +1,28 @@ + + + +FtpRmdir + + + +

FtpRmdir

+

Remove a directory from the remote file system.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpRmdir(const char *path, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
A string containing the name of a remote directory.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpRmdir() sends a remove directory request to the remote +server.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpSetCallback.html b/deps/ftplib-4.0-1/html/FtpSetCallback.html new file mode 100644 index 0000000..6fe63e9 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpSetCallback.html @@ -0,0 +1,78 @@ + + + +FtpSetCallback + + + +

FtpSetCallback

+

Establishes a callback function.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpCallback(FtpCallbackOptions *opt, netbuf *nControl);
+
+

FtpCallbackOptions is declared as follows.

+
+typedef struct FtpCallbackOptions {
+    FtpCallback cbFunc;		/* function to call */
+    void *cbArg;		/* argument to pass to function */
+    unsigned int bytesXferred;	/* callback if this number of bytes transferred */
+    unsigned int idleTime;	/* callback if this many milliseconds have elapsed */
+} FtpCallbackOptions;
+
+

PARAMETERS

+
+
opt
+
The address of a structure that contains a pointer to the callback + function and the criteria for calling it.
+
nControl
+
A handle returned by FtpConnect() +or FtpAccess().
+
+

DESCRIPTION

+

FtpSetCallback() establishes a callback functions and tells FTPlib + when to call it. A data connection inherits the options assigned to + the control connection it is created from. Callbacks are only called + on file data connections.

+

The fields in FtpCallbackStruct are described below.

+
+
cbFunc
+
Specifies the address of a user callback routine.
+
cbArg
+
Specifies an argument to pass to the user's callback +routine.
+
idleTime
+
Specifies the socket idle time in milliseconds that triggers +calling the user's callback routine.
+
bytesXferred
+
Specifies the number of bytes to transfer between calls to the +user's callback routine.
+
+

The user's callback routine is specified as:

+
+typedef int (*FtpCallback)(netbuf *nControl, int xfered, void *arg);
+
+nControl is the data connection in use. xfered specifies +how many bytes of data have been transferred on the +connection. arg is the value passed in the FtpCallbackOptions +field cbArg. +

The user can request to be called back on either of two +events.

+

If the routine should be called when the data socket is idle for +some period of time, pass the number of milliseconds of inactivity +that should trigger a callback in the idleTime field.

+

If the routine should be called when a certain amount of data has +been transferred, specify a non-zero value in bytesXferred. This +value represents the minimum number of bytes to transfer between +callbacks. When using this option, ftplib keeps track of the number of +bytes transferred and calls the user once the specified number of +bytes or more has been transferred. It then resets the count to 0 and +starts again.

+

If the user wishes to continue the transfer, the callback +routine should return true (non-zero). It can abort the transfer by +return zero.

+

RETURN VALUE

+

Returns 1 for success or 0 for failure.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpSite.html b/deps/ftplib-4.0-1/html/FtpSite.html new file mode 100644 index 0000000..4649a12 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpSite.html @@ -0,0 +1,28 @@ + + + +FtpSite + + + +

FtpSite

+

Send a SITE command to the remote server.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpSite(const char *cmd, netbuf *nControl);
+
+

PARAMETERS

+
+
cmd
+
A string containing a 'SITE' subcommand.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpSite() sends the specified command as an argument to a 'SITE' +command.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpSize.html b/deps/ftplib-4.0-1/html/FtpSize.html new file mode 100644 index 0000000..fed0c72 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpSize.html @@ -0,0 +1,38 @@ + + + +FtpSize + + + +

FtpSize

+

Determine size of remote file.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpSize(char *path, unsigned int *size, char mode, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
Name of a file on the remote server.
+
size
+
A pointer to an unsigned integer where the size will be returned.
+
mode
+
Specifies the transfer mode as FTPLIB_ASCII or +FTPLIB_IMAGE.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpSize() attempts to determine the size of a remote file.

+

RETURN VALUE

+

If a good response is received and the size is successfully +parsed out of the result, 1 is returned. Otherwise, 0 is +returned.

+

Some servers may not support the SIZE command. If this request +fails, the size may be available in the response to a RETR +(FtpOpen() with +typ=FTPLIB_FILE_READ).

+ + diff --git a/deps/ftplib-4.0-1/html/FtpSizeLong.html b/deps/ftplib-4.0-1/html/FtpSizeLong.html new file mode 100644 index 0000000..80d0c7b --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpSizeLong.html @@ -0,0 +1,40 @@ + + + +FtpSizeLong + + + +

FtpSizeLong

+

Determine size of remote file.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpSize(char *path, unsigned long long *size, char mode, netbuf *nControl);
+
+

PARAMETERS

+
+
path
+
Name of a file on the remote server.
+
size
+
A pointer to an unsigned 64 bit integer where the size will be returned.
+
mode
+
Specifies the transfer mode as FTPLIB_ASCII or +FTPLIB_IMAGE.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpSize() attempts to determine the size of a remote file.

+

RETURN VALUE

+

If a good response is received and the size is successfully +parsed out of the result, 1 is returned. Otherwise, 0 is +returned.

+

Some servers may not support the SIZE command. If this request +fails, the size may be available in the response to a RETR +(FtpOpen() with +typ=FTPLIB_FILE_READ).

+

This function is identical to FtpSize() +except for the type of the returned value.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpSysType.html b/deps/ftplib-4.0-1/html/FtpSysType.html new file mode 100644 index 0000000..bef3eb9 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpSysType.html @@ -0,0 +1,31 @@ + + + +FtpSysType + + + +

FtpSysType

+

Determine system type of remote server.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpSysType(char *buf, int max, netbuf *nControl);
+
+

PARAMETERS

+
+
buf
+
A pointer to a buffer where the result will be returned.
+
max
+
Specifies the size of the user buffer.
+
nControl
+
A handle returned by FtpConnect().
+
+

DESCRIPTION

+

FtpSysType() issues a SYST command to the remote system and +attempts to parse the system type out of the response and return it +to the user's buffer.

+

RETURN VALUE

+

Returns 1 if successful or 0 on error.

+ + diff --git a/deps/ftplib-4.0-1/html/FtpWrite.html b/deps/ftplib-4.0-1/html/FtpWrite.html new file mode 100644 index 0000000..937cab0 --- /dev/null +++ b/deps/ftplib-4.0-1/html/FtpWrite.html @@ -0,0 +1,33 @@ + + + +FtpWrite + + + +

FtpWrite

+

Write data to a remote file.

+

SYNOPSIS

+
+#include <ftplib.h>
+int FtpWrite(void *buf, int len, netbuf *nData);
+
+

PARAMETERS

+
+
buf
+
A buffer containing the data to be sent to the remote +file.
+
len
+
The number of bytes to be sent from 'buf'.
+
nData
+
A handle returned by FtpAccess().
+
+

DESCRIPTION

+

FtpWrite() sends data to a remote file. If the file was +accessed in record mode, the necessary conversions are +performed.

+

RETURN VALUE

+

Returns the number of bytes sent from the user's buffer or -1 on +error.

+ + diff --git a/deps/ftplib-4.0-1/html/doc.css b/deps/ftplib-4.0-1/html/doc.css new file mode 100644 index 0000000..9419164 --- /dev/null +++ b/deps/ftplib-4.0-1/html/doc.css @@ -0,0 +1,29 @@ +body { + font-family: Georgia, "Times New Roman", serif; + font-size: 0.9em; + background-color: #F8F8F8; + color: #000000; +} +h1, h2, h3 { + font-family: Verdana, Tahoma, "Lucida Grande", Arial, sans-serif; + margin-bottom: .5em; +} +pre, code { + font-family: "Lucida Console", monospace; + font-size: smaller; +} +table, pre, p, li, dt { + margin-left: 2em; + margin-right: 2em; +} +dt { + font-weight: bolder; +} +dd { + margin-left: 4em; + margin-right: 2em; +} +td { + padding-left: 1em; + padding-right: 1em; +} diff --git a/deps/ftplib-4.0-1/html/ftplib.html b/deps/ftplib-4.0-1/html/ftplib.html new file mode 100644 index 0000000..e592890 --- /dev/null +++ b/deps/ftplib-4.0-1/html/ftplib.html @@ -0,0 +1,92 @@ + + + +FTPlib Client FTP Library + + + +

FTPlib Client FTP Library

+

These descriptions apply to FTPlib V4.0.

+

Miscellaneous Functions

+ +

Server Connection

+ +

Directory Functions

+ +

File to File Transfer

+ +

File to Program Transfer

+

These routines allow programs access to the data streams connected +to remote files and directories.

+ +

Utilities

+
    +
  • qftp - Command line ftp utility
    • +
+
+

Last Updated - June 7, 2013

+
Thomas Pfau / +tfpfau@gmail.com
+ + diff --git a/deps/ftplib-4.0-1/html/index.html b/deps/ftplib-4.0-1/html/index.html new file mode 100644 index 0000000..c7072c0 --- /dev/null +++ b/deps/ftplib-4.0-1/html/index.html @@ -0,0 +1,39 @@ + + + +ftplib + + + + +

ftplib

+ +

ftplib is a set of routines that implement the FTP protocol. They +allow applications to create and access remote files through function +calls instead of needing to fork and exec an interactive ftp client +program.

+ +

ftplib has been built and tested on Linux (X86) and OpenVMS (AXP).

+ +

Kits

+
    +
  • ftplib V4.0 June 7, 2013 + +
+ +

Documentation

+

The documentation is included in the kit in html format. Also, the +current working documentation for the release in +progress is available on line.

+ +
+ +

Last Updated - June 7, 2013

+ +
Thomas Pfau / +tfpfau@gmail.com
+ + diff --git a/deps/ftplib-4.0-1/html/qftp.html b/deps/ftplib-4.0-1/html/qftp.html new file mode 100644 index 0000000..ee52d60 --- /dev/null +++ b/deps/ftplib-4.0-1/html/qftp.html @@ -0,0 +1,114 @@ + + + +qftp + + + +

qftp

+

qftp is a utility that performs file transfers using +ftplib based on instructions presented on the command +line.

+

Format

+
+    qftp <action> <host> [ -l user [ -p pass ] ] { options/files }...
+
+    Actions: send, get, dir, list, rm
+
+    Options:
+        -v level        Set verbosity
+        -r rootpath     Change remote working directory
+        -m umask        Set umask for created files
+        -a | -i         Set ascii/image transfer mode
+        -w              Toggle wildcard mode
+        -s cmd          Send cmd as a SITE command
+        -b              Toggle stripping of path from filename
+                        on send
+
+
+
action
+
Specifies what qftp is to do. qftp can +send files to a remote system, get files from a +remote system, remove (rm) files from a remote system, or +retreive a directory of files or a list of files on a +remote system.
+
host
+
Specifies the name of the remote system. An alternate port may +be specified by appending a colon and the port name or number to +the host name.
+
-l user
+
Specifies the username to log in with on host.
+
-p pass
+
Specifies the password to log in with on host. +

If user is not specified, qftp will use +anonymous. If pass is also not specified, qftp +attempts to build a password from the translation of the +environment variable "USER" and the string returned by +gethostname() separated by an "@".

+
+
-v level
+
Specifies the verbosity level. A level of 1 will cause +qftp to display messages indicating successful transfers. A +level of 2 will cause FTP protocol responses to be displayed. A +level of 3 will cause FTP protocol commands to be displayed.
+
-r rootpath
+
Sends a 'change directory' request to the remote server. All +subsequent file names on the command line will be parsed relative +to this new directory.
+
-m umask
+
Sends a request to change the umask to the remote server. This +may not be supported by all servers. It is implemented using the +'SITE' command in the FTP protocol.
+
-a
+
Requests that subsequent files be sent in ascii mode.
+
-i
+
Requests that subsequent files be sent in image mode.
+
-w
+
Toggles handling of filenames to get as wildcards. When a + wildcard filename is encountered it is passed to the server in a + NLST (brief directory) command. qftp will save the list of files + returned and then retrieve each file individually.
+
-s cmd
+
Sends cmd in a SITE command. This can be useful to alter the way + filenames are presented. For example, an OpenVMS FTP server will + strip version numbers from file names after receiving a 'SITE UNIX' + command.
+
-b
+
Toggles stripping of paths from filenames on send. By default, + qftp passes the full path of the input file as specified on the + command line to the remote FTP server as the target filename. This + option will cause qftp to send only the basename of the file.
+
+

qftp reads the command line argument by argument and acts on + each as it comes to it. Most options only change the value of a + variable. The '-m' (umask), '-s' (site), and '-r' (change + directory) options are executed immediately by sending the command + to the server. The '-a' (ascii) and '-i' (image) options save the + type for subsequent transfers. When a filename is encountered it + is sent to the server with the command for the selected action.

+

It is possible to send multiple files with different modes on the + same command line. For example, the following command will send all + text files in ascii mode and all zip files in image mode:

+
+    qftp send srvr -a *.txt -i *.zip
+
+

qftp may optionally be invoked through a softlink. +qftp searches the command which invoked it for 'send', 'get' +or 'dir' and, if found, performs the requested function. In this +case, leave off the action argument on the command line.

+

For example; create the following softlinks:

+
+    ln -s qftp ftpsend
+    ln -s qftp ftpget
+    ln -s qftp ftpdir
+    ln -s qftp ftplist
+    ln -s qftp ftprm
+
+

and then invoke transfers with 'ftpsend' instead of 'qftp send', +etc.

+

If no file names are specified on the command line, qftp +will read file names from stdin. Use your favorite utility to +generate a list of files to send/retreive or type them +interactively.

+ + diff --git a/deps/ftplib-4.0-1/src/Makefile b/deps/ftplib-4.0-1/src/Makefile new file mode 100644 index 0000000..5a2f373 --- /dev/null +++ b/deps/ftplib-4.0-1/src/Makefile @@ -0,0 +1,73 @@ +# +# This makefile contains modifications submitted by Richard Braakman +# (dark@xs4all.nl) for the shared library generation. +# + +# By default, ftplib uses PASV. If you need it to use PORT +# instead, uncomment the next line +#DEFINES = -DFTPLIB_DEFMODE=FTPLIB_PORT + +SONAME = 4 +SOVERSION = $(SONAME).0 + +TARGETS = qftp libftp.so libftp.a qftp.static +OBJECTS = qftp.o ftplib.o +SOURCES = qftp.c ftplib.c + +CFLAGS = -Wall $(DEBUG) -I. $(INCLUDES) $(DEFINES) -Wno-unused-variable -D_FILE_OFFSET_BITS=64 -D__unix__ +LDFLAGS = -L. +DEPFLAGS = + +all : $(TARGETS) + +clean : + rm -f $(OBJECTS) core *.bak + rm -rf unshared + +clobber : clean + rm -f $(TARGETS) .depend + rm -f libftp.so.* + +install : all + install qftp /usr/local/bin + install -m 644 libftp.so.$(SOVERSION) /usr/local/lib + install -m 644 ftplib.h /usr/local/include + (cd /usr/local/lib && \ + ln -sf libftp.so.$(SOVERSION) libftp.so.$(SONAME) && \ + ln -sf libftp.so.$(SONAME) libftp.so) + -(cd /usr/local/bin && \ + for f in ftpdir ftpget ftplist ftprm ftpsend; \ + do ln -s qftp $$f; done) + +depend : + $(CC) $(CFLAGS) -M $(SOURCES) > .depend + +# build without -fPIC +unshared/ftplib.o: ftplib.c ftplib.h + test -d unshared || mkdir unshared + $(CC) -c $(CFLAGS) -D_REENTRANT $< -o $@ + +static : libftp.a qftp.static + +qftp.static : qftp.o libftp.a + $(CC) -o $@ $< libftp.a + +ftplib.o: ftplib.c ftplib.h + $(CC) -c $(CFLAGS) -fPIC -D_REENTRANT $< -o $@ + +libftp.a: unshared/ftplib.o + ar -rcs $@ $< + +libftp.so.$(SOVERSION): ftplib.o + $(CC) -shared -Wl,-soname,libftp.so.$(SONAME) -lc -o $@ $< + +libftp.so: libftp.so.$(SOVERSION) + ln -sf $< libftp.so.$(SONAME) + ln -sf $< $@ + +qftp : qftp.o libftp.so ftplib.h + $(CC) $(LDFLAGS) -o $@ $< -lftp + +ifeq (.depend,$(wildcard .depend)) +include .depend +endif diff --git a/deps/ftplib-4.0-1/src/README b/deps/ftplib-4.0-1/src/README new file mode 100644 index 0000000..5815684 --- /dev/null +++ b/deps/ftplib-4.0-1/src/README @@ -0,0 +1,24 @@ +To build FTPlib on linux, type 'make'. This should produce a shared +library and a static library. It should also create the qftp +executable. 'make install' should install into /usr/local. To +install elsewhere, modify the Makefile. + +To build on MAC, type 'make static'. This should build a static link +library and qftp.static. + +The provided Makefile may work on other unix-like systems although it +will most likely require some modifications. + +To build on OpenVMS, some extra files are provided. DESCRIP.MMS can +be used with MMS or MMK. Options files are provied for VAX, Alpha and +Itanium systems. + +This release was not tested on Microsoft Windows. Previous releases +have built without any problems and I don't believe any significant +changes have ocurred that should cause this release to fail. To build +on Windows using Visual Studio, create a library project for FTPlib +and a command line executable project qftp. Add a dependency from +qftp to FTPlib. 'Build All' should create working files. + +Also not tested but the provided Makefile will probably work with +Cygwin. diff --git a/deps/ftplib-4.0-1/src/descrip.mms b/deps/ftplib-4.0-1/src/descrip.mms new file mode 100644 index 0000000..9ab9361 --- /dev/null +++ b/deps/ftplib-4.0-1/src/descrip.mms @@ -0,0 +1,40 @@ +.ifdef MMSIA64 +SUFFIX = _IA64 +CFLAGS = $(CFLAGS)/define=(_LARGEFILE) +.endif +.ifdef MMSALPHA +SUFFIX = _ALPHA +CFLAGS = $(CFLAGS)/define=(_LARGEFILE) +.endif +.ifdef MMSVAX +XFER_VECTOR = ftplib_vector.obj +.endif + +TARGETS = ftplib$(SUFFIX).exe qftp$(SUFFIX).exe +SHLINKFLAGS = /SHARE=$(MMS$TARGET)/NOMAP + +* : $(TARGETS) + continue + +clean : + if f$search("ftplib.obj") .nes. "" then delete ftplib.obj;* + if f$search("ftplib_alpha.obj") .nes. "" then delete ftplib_alpha.obj;* + if f$search("ftplib.exe") .nes. "" then delete ftplib.exe;* + if f$search("ftplib_alpha.exe") .nes. "" then delete ftplib_alpha.exe;* + if f$search("qftp.obj") .nes. "" then delete qftp.obj;* + if f$search("qftp_alpha.obj") .nes. "" then delete qftp_alpha.obj;* + if f$search("qftp.exe") .nes. "" then delete qftp.exe;* + if f$search("qftp_alpha.exe") .nes. "" then delete qftp_alpha.exe;* + if f$search("ftplib_vector.obj") .nes. "" then delete ftplib_vector.obj;* + +ftplib$(SUFFIX).obj : ftplib.c ftplib.h + $(CC) $(CFLAGS) $< + +ftplib$(SUFFIX).exe : ftplib$(SUFFIX).obj $(XFER_VECTOR) + $(LINK) $(SHLINKFLAGS) ftplib$(SUFFIX).opt/options + +qftp$(SUFFIX).exe : qftp$(SUFFIX).obj + $(LINK) $(LINKFLAGS) qftp$(SUFFIX).opt/options + +qftp$(SUFFIX).obj : qftp.c ftplib.h + $(CC) $(CFLAGS) $< diff --git a/deps/ftplib-4.0-1/src/ftplib.c b/deps/ftplib-4.0-1/src/ftplib.c new file mode 100644 index 0000000..b05a953 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib.c @@ -0,0 +1,1455 @@ +/***************************************************************************/ +/* */ +/* ftplib.c - callable ftp access routines */ +/* Copyright (C) 1996-2001, 2013, 2016 Thomas Pfau, tfpfau@gmail.com */ +/* 1407 Thomas Ave, North Brunswick, NJ, 08902 */ +/* */ +/* This library is free software. You can redistribute it and/or */ +/* modify it under the terms of the Artistic License 2.0. */ +/* */ +/* This library is distributed in the hope that it will be useful, */ +/* but WITHOUT ANY WARRANTY; without even the implied warranty of */ +/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ +/* Artistic License 2.0 for more details. */ +/* */ +/* See the file LICENSE or */ +/* http://www.perlfoundation.org/artistic_license_2_0 */ +/* */ +/***************************************************************************/ + +#if defined(__unix__) || defined(__VMS) +#include +#endif +#if defined(_WIN32) +#include +#endif +#include +#include +#include +#include +#include +#if defined(__unix__) +#include +#include +#include +#include +#include +#include +#elif defined(VMS) +#include +#include +#include +#include +#include +#elif defined(_WIN32) +#include +#endif +#if defined(__APPLE__) +#undef _REENTRANT +#endif + +#define BUILDING_LIBRARY +#include "ftplib.h" + +#if defined(__UINT64_MAX) && !defined(PRIu64) +#if ULONG_MAX == __UINT32_MAX +#define PRIu64 "llu" +#else +#define PRIu64 "lu" +#endif +#endif + +#if defined(_WIN32) +#define SETSOCKOPT_OPTVAL_TYPE (const char *) +#else +#define SETSOCKOPT_OPTVAL_TYPE (void *) +#endif + +#define FTPLIB_BUFSIZ 8192 +#define RESPONSE_BUFSIZ 1024 +#define TMP_BUFSIZ 1024 +#define ACCEPT_TIMEOUT 30 + +#define FTPLIB_CONTROL 0 +#define FTPLIB_READ 1 +#define FTPLIB_WRITE 2 + +#if !defined FTPLIB_DEFMODE +#define FTPLIB_DEFMODE FTPLIB_PASSIVE +#endif + +struct NetBuf { + char *cput,*cget; + int handle; + int cavail,cleft; + char *buf; + int dir; + netbuf *ctrl; + netbuf *data; + int cmode; + struct timeval idletime; + FtpCallback idlecb; + void *idlearg; + unsigned long int xfered; + unsigned long int cbbytes; + unsigned long int xfered1; + char response[RESPONSE_BUFSIZ]; +}; + +static char *version = + "ftplib Release 4.0 07-Jun-2013, copyright 1996-2003, 2013 Thomas Pfau"; + +GLOBALDEF int ftplib_debug = 0; + +#if defined(__unix__) || defined(VMS) +int net_read(int fd, char *buf, size_t len) +{ + while ( 1 ) + { + int c = read(fd, buf, len); + if ( c == -1 ) + { + if ( errno != EINTR && errno != EAGAIN ) + return -1; + } + else + { + return c; + } + } +} + +int net_write(int fd, const char *buf, size_t len) +{ + int done = 0; + while ( len > 0 ) + { + int c = write( fd, buf, len ); + if ( c == -1 ) + { + if ( errno != EINTR && errno != EAGAIN ) + return -1; + } + else if ( c == 0 ) + { + return done; + } + else + { + buf += c; + done += c; + len -= c; + } + } + return done; +} +#define net_close close +#elif defined(_WIN32) +#define net_read(x,y,z) recv(x,y,z,0) +#define net_write(x,y,z) send(x,y,z,0) +#define net_close closesocket +#endif + +#if defined(NEED_MEMCCPY) +/* + * VAX C does not supply a memccpy routine so I provide my own + */ +void *memccpy(void *dest, const void *src, int c, size_t n) +{ + int i=0; + const unsigned char *ip=src; + unsigned char *op=dest; + + while (i < n) + { + if ((*op++ = *ip++) == c) + break; + i++; + } + if (i == n) + return NULL; + return op; +} +#endif +#if defined(NEED_STRDUP) +/* + * strdup - return a malloc'ed copy of a string + */ +char *strdup(const char *src) +{ + int l = strlen(src) + 1; + char *dst = malloc(l); + if (dst) + strcpy(dst,src); + return dst; +} +#endif + +/* + * socket_wait - wait for socket to receive or flush data + * + * return 1 if no user callback, otherwise, return value returned by + * user callback + */ +static int socket_wait(netbuf *ctl) +{ + fd_set fd,*rfd = NULL,*wfd = NULL; + struct timeval tv; + int rv = 0; + if ((ctl->dir == FTPLIB_CONTROL) || (ctl->idlecb == NULL)) + return 1; + if (ctl->dir == FTPLIB_WRITE) + wfd = &fd; + else + rfd = &fd; + FD_ZERO(&fd); + do + { + FD_SET(ctl->handle,&fd); + tv = ctl->idletime; + rv = select(ctl->handle+1, rfd, wfd, NULL, &tv); + if (rv == -1) + { + rv = 0; + strncpy(ctl->ctrl->response, strerror(errno), + sizeof(ctl->ctrl->response)); + break; + } + else if (rv > 0) + { + rv = 1; + break; + } + } + while ((rv = ctl->idlecb(ctl, ctl->xfered, ctl->idlearg))); + return rv; +} + +/* + * read a line of text + * + * return -1 on error or bytecount + */ +static int readline(char *buf,int max,netbuf *ctl) +{ + int x,retval = 0; + char *end,*bp=buf; + int eof = 0; + + if ((ctl->dir != FTPLIB_CONTROL) && (ctl->dir != FTPLIB_READ)) + return -1; + if (max == 0) + return 0; + do + { + if (ctl->cavail > 0) + { + x = (max >= ctl->cavail) ? ctl->cavail : max-1; + end = memccpy(bp,ctl->cget,'\n',x); + if (end != NULL) + x = end - bp; + retval += x; + bp += x; + *bp = '\0'; + max -= x; + ctl->cget += x; + ctl->cavail -= x; + if (end != NULL) + { + bp -= 2; + if (strcmp(bp,"\r\n") == 0) + { + *bp++ = '\n'; + *bp++ = '\0'; + --retval; + } + break; + } + } + if (max == 1) + { + *buf = '\0'; + break; + } + if (ctl->cput == ctl->cget) + { + ctl->cput = ctl->cget = ctl->buf; + ctl->cavail = 0; + ctl->cleft = FTPLIB_BUFSIZ; + } + if (eof) + { + if (retval == 0) + retval = -1; + break; + } + if (!socket_wait(ctl)) + return retval; + if ((x = net_read(ctl->handle,ctl->cput,ctl->cleft)) == -1) + { + if (ftplib_debug) + perror("read"); + retval = -1; + break; + } + if (x == 0) + eof = 1; + ctl->cleft -= x; + ctl->cavail += x; + ctl->cput += x; + } + while (1); + return retval; +} + +/* + * write lines of text + * + * return -1 on error or bytecount + */ +static int writeline(const char *buf, int len, netbuf *nData) +{ + int x, nb=0, w; + const char *ubp = buf; + char *nbp; + char lc=0; + + if (nData->dir != FTPLIB_WRITE) + return -1; + nbp = nData->buf; + for (x=0; x < len; x++) + { + if ((*ubp == '\n') && (lc != '\r')) + { + if (nb == FTPLIB_BUFSIZ) + { + if (!socket_wait(nData)) + return x; + w = net_write(nData->handle, nbp, FTPLIB_BUFSIZ); + if (w != FTPLIB_BUFSIZ) + { + if (ftplib_debug) + printf("net_write(1) returned %d, errno = %d\n", w, errno); + return(-1); + } + nb = 0; + } + nbp[nb++] = '\r'; + } + if (nb == FTPLIB_BUFSIZ) + { + if (!socket_wait(nData)) + return x; + w = net_write(nData->handle, nbp, FTPLIB_BUFSIZ); + if (w != FTPLIB_BUFSIZ) + { + if (ftplib_debug) + printf("net_write(2) returned %d, errno = %d\n", w, errno); + return(-1); + } + nb = 0; + } + nbp[nb++] = lc = *ubp++; + } + if (nb) + { + if (!socket_wait(nData)) + return x; + w = net_write(nData->handle, nbp, nb); + if (w != nb) + { + if (ftplib_debug) + printf("net_write(3) returned %d, errno = %d\n", w, errno); + return(-1); + } + } + return len; +} + +/* + * read a response from the server + * + * return 0 if first char doesn't match + * return 1 if first char matches + */ +static int readresp(char c, netbuf *nControl) +{ + char match[5]; + if (readline(nControl->response,RESPONSE_BUFSIZ,nControl) == -1) + { + if (ftplib_debug) + perror("Control socket read failed"); + return 0; + } + if (ftplib_debug > 1) + fprintf(stderr,"%s",nControl->response); + if (nControl->response[3] == '-') + { + strncpy(match,nControl->response,3); + match[3] = ' '; + match[4] = '\0'; + do + { + if (readline(nControl->response,RESPONSE_BUFSIZ,nControl) == -1) + { + if (ftplib_debug) + perror("Control socket read failed"); + return 0; + } + if (ftplib_debug > 1) + fprintf(stderr,"%s",nControl->response); + } + while (strncmp(nControl->response,match,4)); + } + if (nControl->response[0] == c) + return 1; + return 0; +} + +/* + * FtpInit for stupid operating systems that require it (Windows NT) + */ +GLOBALDEF void FtpInit(void) +{ +#if defined(_WIN32) + WORD wVersionRequested; + WSADATA wsadata; + int err; + wVersionRequested = MAKEWORD(1,1); + if ((err = WSAStartup(wVersionRequested,&wsadata)) != 0) + fprintf(stderr,"Network failed to start: %d\n",err); +#endif +} + +/* + * FtpLastResponse - return a pointer to the last response received + */ +GLOBALDEF char *FtpLastResponse(netbuf *nControl) +{ + if ((nControl) && (nControl->dir == FTPLIB_CONTROL)) + return nControl->response; + return NULL; +} + +/* + * FtpConnect - connect to remote server + * + * return 1 if connected, 0 if not + */ +GLOBALDEF int FtpConnect(const char *host, netbuf **nControl) +{ + int sControl; + struct sockaddr_in sin; + int on=1; + netbuf *ctrl; + char *lhost; + char *pnum; + + memset(&sin,0,sizeof(sin)); + sin.sin_family = AF_INET; + lhost = strdup(host); + pnum = strchr(lhost,':'); + if (pnum == NULL) + pnum = "ftp"; + else + *pnum++ = '\0'; + if (isdigit(*pnum)) + sin.sin_port = htons(atoi(pnum)); + else + { + struct servent *pse; +#if _REENTRANT + struct servent se; + char tmpbuf[TMP_BUFSIZ]; + int i; + if ( ( i = getservbyname_r(pnum,"tcp",&se,tmpbuf,TMP_BUFSIZ,&pse) ) != 0 ) + { + errno = i; + if ( ftplib_debug ) + perror("getservbyname_r"); + free(lhost); + return 0; + } +#else + if ((pse = getservbyname(pnum,"tcp") ) == NULL ) + { + if ( ftplib_debug ) + perror("getservbyname"); + free(lhost); + return 0; + } +#endif + sin.sin_port = pse->s_port; + } + if ((sin.sin_addr.s_addr = inet_addr(lhost)) == INADDR_NONE) + { + struct hostent *phe; +#ifdef _REENTRANT + struct hostent he; + char tmpbuf[TMP_BUFSIZ]; + int i, herr; + if ( ( ( i = gethostbyname_r( lhost, &he, tmpbuf, TMP_BUFSIZ, &phe, &herr ) ) != 0 ) || + ( phe == NULL ) ) + { + if ( ftplib_debug ) + fprintf(stderr, "gethostbyname: %s\n", hstrerror(herr)); + free(lhost); + return 0; + } +#else + if ((phe = gethostbyname(lhost)) == NULL) + { + if (ftplib_debug) + fprintf(stderr, "gethostbyname: %s\n", hstrerror(h_errno)); + free(lhost); + return 0; + } +#endif + memcpy((char *)&sin.sin_addr, phe->h_addr, phe->h_length); + } + free(lhost); + sControl = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP); + if (sControl == -1) + { + if (ftplib_debug) + perror("socket"); + return 0; + } + if (setsockopt(sControl,SOL_SOCKET,SO_REUSEADDR, + SETSOCKOPT_OPTVAL_TYPE &on, sizeof(on)) == -1) + { + if (ftplib_debug) + perror("setsockopt"); + net_close(sControl); + return 0; + } + if (connect(sControl, (struct sockaddr *)&sin, sizeof(sin)) == -1) + { + if (ftplib_debug) + perror("connect"); + net_close(sControl); + return 0; + } + ctrl = calloc(1,sizeof(netbuf)); + if (ctrl == NULL) + { + if (ftplib_debug) + perror("calloc"); + net_close(sControl); + return 0; + } + ctrl->buf = malloc(FTPLIB_BUFSIZ); + if (ctrl->buf == NULL) + { + if (ftplib_debug) + perror("calloc"); + net_close(sControl); + free(ctrl); + return 0; + } + ctrl->handle = sControl; + ctrl->dir = FTPLIB_CONTROL; + ctrl->ctrl = NULL; + ctrl->data = NULL; + ctrl->cmode = FTPLIB_DEFMODE; + ctrl->idlecb = NULL; + ctrl->idletime.tv_sec = ctrl->idletime.tv_usec = 0; + ctrl->idlearg = NULL; + ctrl->xfered = 0; + ctrl->xfered1 = 0; + ctrl->cbbytes = 0; + if (readresp('2', ctrl) == 0) + { + net_close(sControl); + free(ctrl->buf); + free(ctrl); + return 0; + } + *nControl = ctrl; + return 1; +} + +GLOBALDEF int FtpSetCallback(const FtpCallbackOptions *opt, netbuf *nControl) +{ + nControl->idlecb = opt->cbFunc; + nControl->idlearg = opt->cbArg; + nControl->idletime.tv_sec = opt->idleTime / 1000; + nControl->idletime.tv_usec = (opt->idleTime % 1000) * 1000; + nControl->cbbytes = opt->bytesXferred; + return 1; +} +GLOBALDEF int FtpClearCallback(netbuf *nControl) +{ + nControl->idlecb = NULL; + nControl->idlearg = NULL; + nControl->idletime.tv_sec = 0; + nControl->idletime.tv_usec = 0; + nControl->cbbytes = 0; + return 1; +} +/* + * FtpOptions - change connection options + * + * returns 1 if successful, 0 on error + */ +GLOBALDEF int FtpOptions(int opt, long val, netbuf *nControl) +{ + int v,rv=0; + switch (opt) + { + case FTPLIB_CONNMODE: + v = (int) val; + if ((v == FTPLIB_PASSIVE) || (v == FTPLIB_PORT)) + { + nControl->cmode = v; + rv = 1; + } + break; + case FTPLIB_CALLBACK: + nControl->idlecb = (FtpCallback) val; + rv = 1; + break; + case FTPLIB_IDLETIME: + v = (int) val; + rv = 1; + nControl->idletime.tv_sec = v / 1000; + nControl->idletime.tv_usec = (v % 1000) * 1000; + break; + case FTPLIB_CALLBACKARG: + rv = 1; + nControl->idlearg = (void *) val; + break; + case FTPLIB_CALLBACKBYTES: + rv = 1; + nControl->cbbytes = (int) val; + break; + } + return rv; +} + +/* + * FtpSendCmd - send a command and wait for expected response + * + * return 1 if proper response received, 0 otherwise + */ +static int FtpSendCmd(const char *cmd, char expresp, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + if (nControl->dir != FTPLIB_CONTROL) + return 0; + if (ftplib_debug > 2) + fprintf(stderr,"%s\n",cmd); + if ((strlen(cmd) + 3) > sizeof(buf)) + return 0; + sprintf(buf,"%s\r\n",cmd); + if (net_write(nControl->handle,buf,strlen(buf)) <= 0) + { + if (ftplib_debug) + perror("write"); + return 0; + } + return readresp(expresp, nControl); +} + +/* + * FtpLogin - log in to remote server + * + * return 1 if logged in, 0 otherwise + */ +GLOBALDEF int FtpLogin(const char *user, const char *pass, netbuf *nControl) +{ + char tempbuf[64]; + + if (((strlen(user) + 7) > sizeof(tempbuf)) || + ((strlen(pass) + 7) > sizeof(tempbuf))) + return 0; + sprintf(tempbuf,"USER %s",user); + if (!FtpSendCmd(tempbuf,'3',nControl)) + { + if (nControl->response[0] == '2') + return 1; + return 0; + } + sprintf(tempbuf,"PASS %s",pass); + return FtpSendCmd(tempbuf,'2',nControl); +} + +/* + * FtpOpenPort - set up data connection + * + * return 1 if successful, 0 otherwise + */ +static int FtpOpenPort(netbuf *nControl, netbuf **nData, int mode, int dir) +{ + int sData; + union { + struct sockaddr sa; + struct sockaddr_in in; + } sin; + struct linger lng = { 0, 0 }; + unsigned int l; + int on=1; + netbuf *ctrl; + char *cp; + unsigned int v[6]; + char buf[TMP_BUFSIZ]; + + if (nControl->dir != FTPLIB_CONTROL) + return -1; + if ((dir != FTPLIB_READ) && (dir != FTPLIB_WRITE)) + { + sprintf(nControl->response, "Invalid direction %d\n", dir); + return -1; + } + if ((mode != FTPLIB_ASCII) && (mode != FTPLIB_IMAGE)) + { + sprintf(nControl->response, "Invalid mode %c\n", mode); + return -1; + } + l = sizeof(sin); + if (nControl->cmode == FTPLIB_PASSIVE) + { + memset(&sin, 0, l); + sin.in.sin_family = AF_INET; + if (!FtpSendCmd("PASV",'2',nControl)) + return -1; + cp = strchr(nControl->response,'('); + if (cp == NULL) + return -1; + cp++; + sscanf(cp,"%u,%u,%u,%u,%u,%u",&v[2],&v[3],&v[4],&v[5],&v[0],&v[1]); + sin.sa.sa_data[2] = v[2]; + sin.sa.sa_data[3] = v[3]; + sin.sa.sa_data[4] = v[4]; + sin.sa.sa_data[5] = v[5]; + sin.sa.sa_data[0] = v[0]; + sin.sa.sa_data[1] = v[1]; + } + else + { + if (getsockname(nControl->handle, &sin.sa, &l) < 0) + { + if (ftplib_debug) + perror("getsockname"); + return -1; + } + } + sData = socket(PF_INET,SOCK_STREAM,IPPROTO_TCP); + if (sData == -1) + { + if (ftplib_debug) + perror("socket"); + return -1; + } + if (setsockopt(sData,SOL_SOCKET,SO_REUSEADDR, + SETSOCKOPT_OPTVAL_TYPE &on,sizeof(on)) == -1) + { + if (ftplib_debug) + perror("setsockopt"); + net_close(sData); + return -1; + } + if (setsockopt(sData,SOL_SOCKET,SO_LINGER, + SETSOCKOPT_OPTVAL_TYPE &lng,sizeof(lng)) == -1) + { + if (ftplib_debug) + perror("setsockopt"); + net_close(sData); + return -1; + } + if (nControl->cmode == FTPLIB_PASSIVE) + { + if (connect(sData, &sin.sa, sizeof(sin.sa)) == -1) + { + if (ftplib_debug) + perror("connect"); + net_close(sData); + return -1; + } + } + else + { + sin.in.sin_port = 0; + if (bind(sData, &sin.sa, sizeof(sin)) == -1) + { + if (ftplib_debug) + perror("bind"); + net_close(sData); + return -1; + } + if (listen(sData, 1) < 0) + { + if (ftplib_debug) + perror("listen"); + net_close(sData); + return -1; + } + if (getsockname(sData, &sin.sa, &l) < 0) + return -1; + sprintf(buf, "PORT %d,%d,%d,%d,%d,%d", + (unsigned char) sin.sa.sa_data[2], + (unsigned char) sin.sa.sa_data[3], + (unsigned char) sin.sa.sa_data[4], + (unsigned char) sin.sa.sa_data[5], + (unsigned char) sin.sa.sa_data[0], + (unsigned char) sin.sa.sa_data[1]); + if (!FtpSendCmd(buf,'2',nControl)) + { + net_close(sData); + return -1; + } + } + ctrl = calloc(1,sizeof(netbuf)); + if (ctrl == NULL) + { + if (ftplib_debug) + perror("calloc"); + net_close(sData); + return -1; + } + if ((mode == 'A') && ((ctrl->buf = malloc(FTPLIB_BUFSIZ)) == NULL)) + { + if (ftplib_debug) + perror("calloc"); + net_close(sData); + free(ctrl); + return -1; + } + ctrl->handle = sData; + ctrl->dir = dir; + ctrl->idletime = nControl->idletime; + ctrl->idlearg = nControl->idlearg; + ctrl->xfered = 0; + ctrl->xfered1 = 0; + ctrl->cbbytes = nControl->cbbytes; + ctrl->ctrl = nControl; + if (ctrl->idletime.tv_sec || ctrl->idletime.tv_usec || ctrl->cbbytes) + ctrl->idlecb = nControl->idlecb; + else + ctrl->idlecb = NULL; + nControl->data = ctrl; + *nData = ctrl; + return 1; +} + +/* + * FtpAcceptConnection - accept connection from server + * + * return 1 if successful, 0 otherwise + */ +static int FtpAcceptConnection(netbuf *nData, netbuf *nControl) +{ + int sData; + struct sockaddr addr; + unsigned int l; + int i; + struct timeval tv; + fd_set mask; + int rv; + + FD_ZERO(&mask); + FD_SET(nControl->handle, &mask); + FD_SET(nData->handle, &mask); + tv.tv_usec = 0; + tv.tv_sec = ACCEPT_TIMEOUT; + i = nControl->handle; + if (i < nData->handle) + i = nData->handle; + i = select(i+1, &mask, NULL, NULL, &tv); + if (i == -1) + { + strncpy(nControl->response, strerror(errno), + sizeof(nControl->response)); + net_close(nData->handle); + nData->handle = 0; + rv = 0; + } + else if (i == 0) + { + strcpy(nControl->response, "timed out waiting for connection"); + net_close(nData->handle); + nData->handle = 0; + rv = 0; + } + else + { + if (FD_ISSET(nData->handle, &mask)) + { + l = sizeof(addr); + sData = accept(nData->handle, &addr, &l); + i = errno; + net_close(nData->handle); + if (sData > 0) + { + rv = 1; + nData->handle = sData; + } + else + { + strncpy(nControl->response, strerror(i), + sizeof(nControl->response)); + nData->handle = 0; + rv = 0; + } + } + else if (FD_ISSET(nControl->handle, &mask)) + { + net_close(nData->handle); + nData->handle = 0; + readresp('2', nControl); + rv = 0; + } + } + return rv; +} + +/* + * FtpAccess - return a handle for a data stream + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpAccess(const char *path, int typ, int mode, netbuf *nControl, + netbuf **nData) +{ + char buf[TMP_BUFSIZ]; + int dir; + if ((path == NULL) && + ((typ == FTPLIB_FILE_WRITE) || (typ == FTPLIB_FILE_READ))) + { + sprintf(nControl->response, + "Missing path argument for file transfer\n"); + return 0; + } + sprintf(buf, "TYPE %c", mode); + if (!FtpSendCmd(buf, '2', nControl)) + return 0; + switch (typ) + { + case FTPLIB_DIR: + strcpy(buf,"NLST"); + dir = FTPLIB_READ; + break; + case FTPLIB_DIR_VERBOSE: + strcpy(buf,"LIST"); + dir = FTPLIB_READ; + break; + case FTPLIB_FILE_READ: + strcpy(buf,"RETR"); + dir = FTPLIB_READ; + break; + case FTPLIB_FILE_WRITE: + strcpy(buf,"STOR"); + dir = FTPLIB_WRITE; + break; + default: + sprintf(nControl->response, "Invalid open type %d\n", typ); + return 0; + } + if (path != NULL) + { + int i = strlen(buf); + buf[i++] = ' '; + if ((strlen(path) + i + 1) >= sizeof(buf)) + return 0; + strcpy(&buf[i],path); + } + if (FtpOpenPort(nControl, nData, mode, dir) == -1) + return 0; + if (!FtpSendCmd(buf, '1', nControl)) + { + FtpClose(*nData); + *nData = NULL; + return 0; + } + if (nControl->cmode == FTPLIB_PORT) + { + if (!FtpAcceptConnection(*nData,nControl)) + { + FtpClose(*nData); + *nData = NULL; + nControl->data = NULL; + return 0; + } + } + return 1; +} + +/* + * FtpRead - read from a data connection + */ +GLOBALDEF int FtpRead(void *buf, int max, netbuf *nData) +{ + int i; + if (nData->dir != FTPLIB_READ) + return 0; + if (nData->buf) + i = readline(buf, max, nData); + else + { + i = socket_wait(nData); + if (i != 1) + return 0; + i = net_read(nData->handle, buf, max); + } + if (i == -1) + return 0; + nData->xfered += i; + if (nData->idlecb && nData->cbbytes) + { + nData->xfered1 += i; + if (nData->xfered1 > nData->cbbytes) + { + if (nData->idlecb(nData, nData->xfered, nData->idlearg) == 0) + return 0; + nData->xfered1 = 0; + } + } + return i; +} + +/* + * FtpWrite - write to a data connection + */ +GLOBALDEF int FtpWrite(const void *buf, int len, netbuf *nData) +{ + int i; + if (nData->dir != FTPLIB_WRITE) + return 0; + if (nData->buf) + i = writeline(buf, len, nData); + else + { + socket_wait(nData); + i = net_write(nData->handle, buf, len); + } + if (i == -1) + return 0; + nData->xfered += i; + if (nData->idlecb && nData->cbbytes) + { + nData->xfered1 += i; + if (nData->xfered1 > nData->cbbytes) + { + nData->idlecb(nData, nData->xfered, nData->idlearg); + nData->xfered1 = 0; + } + } + return i; +} + +/* + * FtpClose - close a data connection + */ +GLOBALDEF int FtpClose(netbuf *nData) +{ + netbuf *ctrl; + switch (nData->dir) + { + case FTPLIB_WRITE: + /* potential problem - if buffer flush fails, how to notify user? */ + if (nData->buf != NULL) + writeline(NULL, 0, nData); + case FTPLIB_READ: + if (nData->buf) + free(nData->buf); + shutdown(nData->handle,2); + net_close(nData->handle); + ctrl = nData->ctrl; + free(nData); + ctrl->data = NULL; + if (ctrl && ctrl->response[0] != '4' && ctrl->response[0] != '5') + { + return(readresp('2', ctrl)); + } + return 1; + case FTPLIB_CONTROL: + if (nData->data) + { + nData->ctrl = NULL; + FtpClose(nData->data); + } + net_close(nData->handle); + free(nData); + return 0; + } + return 1; +} + +/* + * FtpSite - send a SITE command + * + * return 1 if command successful, 0 otherwise + */ +GLOBALDEF int FtpSite(const char *cmd, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + + if ((strlen(cmd) + 7) > sizeof(buf)) + return 0; + sprintf(buf,"SITE %s",cmd); + if (!FtpSendCmd(buf,'2',nControl)) + return 0; + return 1; +} + +/* + * FtpSysType - send a SYST command + * + * Fills in the user buffer with the remote system type. If more + * information from the response is required, the user can parse + * it out of the response buffer returned by FtpLastResponse(). + * + * return 1 if command successful, 0 otherwise + */ +GLOBALDEF int FtpSysType(char *buf, int max, netbuf *nControl) +{ + int l = max; + char *b = buf; + char *s; + if (!FtpSendCmd("SYST",'2',nControl)) + return 0; + s = &nControl->response[4]; + while ((--l) && (*s != ' ')) + *b++ = *s++; + *b++ = '\0'; + return 1; +} + +/* + * FtpMkdir - create a directory at server + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpMkdir(const char *path, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + + if ((strlen(path) + 6) > sizeof(buf)) + return 0; + sprintf(buf,"MKD %s",path); + if (!FtpSendCmd(buf,'2', nControl)) + return 0; + return 1; +} + +/* + * FtpChdir - change path at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpChdir(const char *path, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + + if ((strlen(path) + 6) > sizeof(buf)) + return 0; + sprintf(buf,"CWD %s",path); + if (!FtpSendCmd(buf,'2',nControl)) + return 0; + return 1; +} + +/* + * FtpCDUp - move to parent directory at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpCDUp(netbuf *nControl) +{ + if (!FtpSendCmd("CDUP",'2',nControl)) + return 0; + return 1; +} + +/* + * FtpRmdir - remove directory at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpRmdir(const char *path, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + + if ((strlen(path) + 6) > sizeof(buf)) + return 0; + sprintf(buf,"RMD %s",path); + if (!FtpSendCmd(buf,'2',nControl)) + return 0; + return 1; +} + +/* + * FtpPwd - get working directory at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpPwd(char *path, int max, netbuf *nControl) +{ + int l = max; + char *b = path; + char *s; + if (!FtpSendCmd("PWD",'2',nControl)) + return 0; + s = strchr(nControl->response, '"'); + if (s == NULL) + return 0; + s++; + while ((--l) && (*s) && (*s != '"')) + *b++ = *s++; + *b++ = '\0'; + return 1; +} + +/* + * FtpXfer - issue a command and transfer data + * + * return 1 if successful, 0 otherwise + */ +static int FtpXfer(const char *localfile, const char *path, + netbuf *nControl, int typ, int mode) +{ + int l,c; + char *dbuf; + FILE *local = NULL; + netbuf *nData; + int rv=1; + + if (localfile != NULL) + { + char ac[4]; + memset( ac, 0, sizeof(ac) ); + if (typ == FTPLIB_FILE_WRITE) + ac[0] = 'r'; + else + ac[0] = 'w'; + if (mode == FTPLIB_IMAGE) + ac[1] = 'b'; + local = fopen(localfile, ac); + if (local == NULL) + { + strncpy(nControl->response, strerror(errno), + sizeof(nControl->response)); + return 0; + } + } + if (local == NULL) + local = (typ == FTPLIB_FILE_WRITE) ? stdin : stdout; + if (!FtpAccess(path, typ, mode, nControl, &nData)) + { + if (localfile) + { + fclose(local); + if ( typ == FTPLIB_FILE_READ ) + unlink(localfile); + } + return 0; + } + dbuf = malloc(FTPLIB_BUFSIZ); + if (typ == FTPLIB_FILE_WRITE) + { + while ((l = fread(dbuf, 1, FTPLIB_BUFSIZ, local)) > 0) + { + if ((c = FtpWrite(dbuf, l, nData)) < l) + { + printf("short write: passed %d, wrote %d\n", l, c); + rv = 0; + break; + } + } + } + else + { + while ((l = FtpRead(dbuf, FTPLIB_BUFSIZ, nData)) > 0) + { + if (fwrite(dbuf, 1, l, local) == 0) + { + if (ftplib_debug) + perror("localfile write"); + rv = 0; + break; + } + } + } + free(dbuf); + fflush(local); + if (localfile != NULL) + fclose(local); + FtpClose(nData); + return rv; +} + +/* + * FtpNlst - issue an NLST command and write response to output + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpNlst(const char *outputfile, const char *path, + netbuf *nControl) +{ + return FtpXfer(outputfile, path, nControl, FTPLIB_DIR, FTPLIB_ASCII); +} + +/* + * FtpDir - issue a LIST command and write response to output + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpDir(const char *outputfile, const char *path, netbuf *nControl) +{ + return FtpXfer(outputfile, path, nControl, FTPLIB_DIR_VERBOSE, FTPLIB_ASCII); +} + +/* + * FtpSize - determine the size of a remote file + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpSize(const char *path, unsigned int *size, char mode, netbuf *nControl) +{ + char cmd[TMP_BUFSIZ]; + int resp,rv=1; + unsigned int sz; + + if ((strlen(path) + 7) > sizeof(cmd)) + return 0; + sprintf(cmd, "TYPE %c", mode); + if (!FtpSendCmd(cmd, '2', nControl)) + return 0; + sprintf(cmd,"SIZE %s",path); + if (!FtpSendCmd(cmd,'2',nControl)) + rv = 0; + else + { + if (sscanf(nControl->response, "%d %u", &resp, &sz) == 2) + *size = sz; + else + rv = 0; + } + return rv; +} + +#if defined(__UINT64_MAX) +/* + * FtpSizeLong - determine the size of a remote file + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpSizeLong(const char *path, fsz_t *size, char mode, netbuf *nControl) +{ + char cmd[TMP_BUFSIZ]; + int resp,rv=1; + fsz_t sz; + + if ((strlen(path) + 7) > sizeof(cmd)) + return 0; + sprintf(cmd, "TYPE %c", mode); + if (!FtpSendCmd(cmd, '2', nControl)) + return 0; + sprintf(cmd,"SIZE %s",path); + if (!FtpSendCmd(cmd,'2',nControl)) + rv = 0; + else + { + if (sscanf(nControl->response, "%d %" PRIu64 "", &resp, &sz) == 2) + *size = sz; + else + rv = 0; + } + return rv; +} +#endif + +/* + * FtpModDate - determine the modification date of a remote file + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpModDate(const char *path, char *dt, int max, netbuf *nControl) +{ + char buf[TMP_BUFSIZ]; + int rv = 1; + + if ((strlen(path) + 7) > sizeof(buf)) + return 0; + sprintf(buf,"MDTM %s",path); + if (!FtpSendCmd(buf,'2',nControl)) + rv = 0; + else + strncpy(dt, &nControl->response[4], max); + return rv; +} + +/* + * FtpGet - issue a GET command and write received data to output + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpGet(const char *outputfile, const char *path, + char mode, netbuf *nControl) +{ + return FtpXfer(outputfile, path, nControl, FTPLIB_FILE_READ, mode); +} + +/* + * FtpPut - issue a PUT command and send data from input + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpPut(const char *inputfile, const char *path, char mode, + netbuf *nControl) +{ + return FtpXfer(inputfile, path, nControl, FTPLIB_FILE_WRITE, mode); +} + +/* + * FtpRename - rename a file at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpRename(const char *src, const char *dst, netbuf *nControl) +{ + char cmd[TMP_BUFSIZ]; + + if (((strlen(src) + 7) > sizeof(cmd)) || + ((strlen(dst) + 7) > sizeof(cmd))) + return 0; + sprintf(cmd,"RNFR %s",src); + if (!FtpSendCmd(cmd,'3',nControl)) + return 0; + sprintf(cmd,"RNTO %s",dst); + if (!FtpSendCmd(cmd,'2',nControl)) + return 0; + return 1; +} + +/* + * FtpDelete - delete a file at remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF int FtpDelete(const char *fnm, netbuf *nControl) +{ + char cmd[TMP_BUFSIZ]; + + if ((strlen(fnm) + 7) > sizeof(cmd)) + return 0; + sprintf(cmd,"DELE %s",fnm); + if (!FtpSendCmd(cmd,'2', nControl)) + return 0; + return 1; +} + +/* + * FtpQuit - disconnect from remote + * + * return 1 if successful, 0 otherwise + */ +GLOBALDEF void FtpQuit(netbuf *nControl) +{ + if (nControl->dir != FTPLIB_CONTROL) + return; + FtpSendCmd("QUIT",'2',nControl); + net_close(nControl->handle); + free(nControl->buf); + free(nControl); +} diff --git a/deps/ftplib-4.0-1/src/ftplib.h b/deps/ftplib-4.0-1/src/ftplib.h new file mode 100644 index 0000000..82b90a9 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib.h @@ -0,0 +1,120 @@ +/***************************************************************************/ +/* */ +/* ftplib.h - header file for callable ftp access routines */ +/* Copyright (C) 1996-2001, 2013, 2016 Thomas Pfau, tfpfau@gmail.com */ +/* 1407 Thomas Ave, North Brunswick, NJ, 08902 */ +/* */ +/* This library is free software. You can redistribute it and/or */ +/* modify it under the terms of the Artistic License 2.0. */ +/* */ +/* This library is distributed in the hope that it will be useful, */ +/* but WITHOUT ANY WARRANTY; without even the implied warranty of */ +/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ +/* Artistic License 2.0 for more details. */ +/* */ +/* See the file LICENSE or */ +/* http://www.perlfoundation.org/artistic_license_2_0 */ +/* */ +/***************************************************************************/ + +#if !defined(__FTPLIB_H) +#define __FTPLIB_H + +#if defined(__unix__) || defined(VMS) +#define GLOBALDEF +#define GLOBALREF extern +#elif defined(_WIN32) +#if defined BUILDING_LIBRARY +#define GLOBALDEF __declspec(dllexport) +#define GLOBALREF __declspec(dllexport) +#else +#define GLOBALREF __declspec(dllimport) +#endif +#endif + +#include +#include + +/* FtpAccess() type codes */ +#define FTPLIB_DIR 1 +#define FTPLIB_DIR_VERBOSE 2 +#define FTPLIB_FILE_READ 3 +#define FTPLIB_FILE_WRITE 4 + +/* FtpAccess() mode codes */ +#define FTPLIB_ASCII 'A' +#define FTPLIB_IMAGE 'I' +#define FTPLIB_TEXT FTPLIB_ASCII +#define FTPLIB_BINARY FTPLIB_IMAGE + +/* connection modes */ +#define FTPLIB_PASSIVE 1 +#define FTPLIB_PORT 2 + +/* connection option names */ +#define FTPLIB_CONNMODE 1 +#define FTPLIB_CALLBACK 2 +#define FTPLIB_IDLETIME 3 +#define FTPLIB_CALLBACKARG 4 +#define FTPLIB_CALLBACKBYTES 5 + +#ifdef __cplusplus +extern "C" { +#endif + +#if defined(__UINT64_MAX) +typedef uint64_t fsz_t; +#else +typedef uint32_t fsz_t; +#endif + +typedef struct NetBuf netbuf; +typedef int (*FtpCallback)(netbuf *nControl, fsz_t xfered, void *arg); + +typedef struct FtpCallbackOptions { + FtpCallback cbFunc; /* function to call */ + void *cbArg; /* argument to pass to function */ + unsigned int bytesXferred; /* callback if this number of bytes transferred */ + unsigned int idleTime; /* callback if this many milliseconds have elapsed */ +} FtpCallbackOptions; + +GLOBALREF int ftplib_debug; +GLOBALREF void FtpInit(void); +GLOBALREF char *FtpLastResponse(netbuf *nControl); +GLOBALREF int FtpConnect(const char *host, netbuf **nControl); +GLOBALREF int FtpOptions(int opt, long val, netbuf *nControl); +GLOBALREF int FtpSetCallback(const FtpCallbackOptions *opt, netbuf *nControl); +GLOBALREF int FtpClearCallback(netbuf *nControl); +GLOBALREF int FtpLogin(const char *user, const char *pass, netbuf *nControl); +GLOBALREF int FtpAccess(const char *path, int typ, int mode, netbuf *nControl, + netbuf **nData); +GLOBALREF int FtpRead(void *buf, int max, netbuf *nData); +GLOBALREF int FtpWrite(const void *buf, int len, netbuf *nData); +GLOBALREF int FtpClose(netbuf *nData); +GLOBALREF int FtpSite(const char *cmd, netbuf *nControl); +GLOBALREF int FtpSysType(char *buf, int max, netbuf *nControl); +GLOBALREF int FtpMkdir(const char *path, netbuf *nControl); +GLOBALREF int FtpChdir(const char *path, netbuf *nControl); +GLOBALREF int FtpCDUp(netbuf *nControl); +GLOBALREF int FtpRmdir(const char *path, netbuf *nControl); +GLOBALREF int FtpPwd(char *path, int max, netbuf *nControl); +GLOBALREF int FtpNlst(const char *output, const char *path, netbuf *nControl); +GLOBALREF int FtpDir(const char *output, const char *path, netbuf *nControl); +GLOBALREF int FtpSize(const char *path, unsigned int *size, char mode, netbuf *nControl); +#if defined(__UINT64_MAX) +GLOBALREF int FtpSizeLong(const char *path, fsz_t *size, char mode, netbuf *nControl); +#endif +GLOBALREF int FtpModDate(const char *path, char *dt, int max, netbuf *nControl); +GLOBALREF int FtpGet(const char *output, const char *path, char mode, + netbuf *nControl); +GLOBALREF int FtpPut(const char *input, const char *path, char mode, + netbuf *nControl); +GLOBALREF int FtpRename(const char *src, const char *dst, netbuf *nControl); +GLOBALREF int FtpDelete(const char *fnm, netbuf *nControl); +GLOBALREF void FtpQuit(netbuf *nControl); + +#ifdef __cplusplus +}; +#endif + +#endif /* __FTPLIB_H */ diff --git a/deps/ftplib-4.0-1/src/ftplib.opt b/deps/ftplib-4.0-1/src/ftplib.opt new file mode 100644 index 0000000..5838062 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib.opt @@ -0,0 +1,8 @@ +ident=V4.0 +gsmatch=lequal,4,0 + +ftplib.obj +ftplib_vector.obj + +collect=transfer_vectors,ftplib_vector +universal=ftplib_debug diff --git a/deps/ftplib-4.0-1/src/ftplib_alpha.opt b/deps/ftplib-4.0-1/src/ftplib_alpha.opt new file mode 100644 index 0000000..6f287b4 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib_alpha.opt @@ -0,0 +1,35 @@ +ident=V4.0 +gsmatch=lequal,4,0 + +ftplib_alpha.obj + +symbol_vector=(- + FTPACCESS=procedure,- + FTPCHDIR=procedure,- + FTPCLOSE=procedure,- + FTPCONNECT=procedure,- + FTPDELETE=procedure,- + FTPDIR=procedure,- + FTPGET=procedure,- + FTPINIT=procedure,- + FTPLASTRESPONSE=procedure,- + FTPLIB_DEBUG=data,- + FTPLOGIN=procedure,- + FTPMKDIR=procedure,- + FTPNLST=procedure,- + FTPPUT=procedure,- + FTPQUIT=procedure,- + FTPREAD=procedure,- + FTPRENAME=procedure,- + FTPRMDIR=procedure,- + FTPSITE=procedure,- + FTPWRITE=procedure,- + FTPPWD=procedure,- + FTPSYSTYPE=procedure,- + FTPCDUP=procedure,- + FTPSIZE=procedure,- + FTPMODDATE=procedure,- + FTPOPTIONS=procedure,- + FTPSIZELONG=procedure,- + FTPSETCALLBACK=procedure,- + FTPCLEARCALLBACK=procedure) diff --git a/deps/ftplib-4.0-1/src/ftplib_ia64.opt b/deps/ftplib-4.0-1/src/ftplib_ia64.opt new file mode 100644 index 0000000..ef38550 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib_ia64.opt @@ -0,0 +1,35 @@ +ident=V4.0 +gsmatch=lequal,4,0 + +ftplib_ia64.obj + +symbol_vector=(- + FTPACCESS=procedure,- + FTPCHDIR=procedure,- + FTPCLOSE=procedure,- + FTPCONNECT=procedure,- + FTPDELETE=procedure,- + FTPDIR=procedure,- + FTPGET=procedure,- + FTPINIT=procedure,- + FTPLASTRESPONSE=procedure,- + FTPLIB_DEBUG=data,- + FTPLOGIN=procedure,- + FTPMKDIR=procedure,- + FTPNLST=procedure,- + FTPPUT=procedure,- + FTPQUIT=procedure,- + FTPREAD=procedure,- + FTPRENAME=procedure,- + FTPRMDIR=procedure,- + FTPSITE=procedure,- + FTPWRITE=procedure,- + FTPPWD=procedure,- + FTPSYSTYPE=procedure,- + FTPCDUP=procedure,- + FTPSIZE=procedure,- + FTPMODDATE=procedure,- + FTPOPTIONS=procedure,- + FTPSIZELONG=procedure,- + FTPSETCALLBACK=procedure,- + FTPCLEARCALLBACK=procedure) diff --git a/deps/ftplib-4.0-1/src/ftplib_vector.mar b/deps/ftplib-4.0-1/src/ftplib_vector.mar new file mode 100644 index 0000000..99232c2 --- /dev/null +++ b/deps/ftplib-4.0-1/src/ftplib_vector.mar @@ -0,0 +1,36 @@ + .title ftplib_vector + .macro xfer rtn + .align quad + .transfer rtn + .mask rtn + jmp rtn+2 + .endm + .psect ftplib_vector,quad + xfer FTPACCESS + xfer FTPCHDIR + xfer FTPCLOSE + xfer FTPCONNECT + xfer FTPDELETE + xfer FTPDIR + xfer FTPGET + xfer FTPINIT + xfer FTPLASTRESPONSE + xfer FTPLOGIN + xfer FTPMKDIR + xfer FTPNLST + xfer FTPPUT + xfer FTPQUIT + xfer FTPREAD + xfer FTPRENAME + xfer FTPRMDIR + xfer FTPSITE + xfer FTPWRITE + xfer FTPPWD + xfer FTPSYSTYPE + xfer FTPCDUP + xfer FTPSIZE + xfer FTPMODDATE + xfer FTPOPTIONS + xfer FTPSETCALLBACK + xfer FTPCLEARCALLBACK + .end diff --git a/deps/ftplib-4.0-1/src/qftp.c b/deps/ftplib-4.0-1/src/qftp.c new file mode 100644 index 0000000..eaf31fb --- /dev/null +++ b/deps/ftplib-4.0-1/src/qftp.c @@ -0,0 +1,470 @@ +/***************************************************************************/ +/* */ +/* qftp.c - command line driven ftp file transfer program */ +/* Copyright (C) 1996-2001, 2013, 2016 Thomas Pfau, tfpfau@gmail.com */ +/* 1407 Thomas Ave, North Brunswick, NJ, 08902 */ +/* */ +/* This library is free software. You can redistribute it and/or */ +/* modify it under the terms of the Artistic License 2.0. */ +/* */ +/* This library is distributed in the hope that it will be useful, */ +/* but WITHOUT ANY WARRANTY; without even the implied warranty of */ +/* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the */ +/* Artistic License 2.0 for more details. */ +/* */ +/* See the file LICENSE or */ +/* http://www.perlfoundation.org/artistic_license_2_0 */ +/* */ +/***************************************************************************/ + +#if defined(__unix__) || defined(__VMS) +#include +#endif +#include +#include +#include +#include +#include +#if defined(_WIN32) +#include +#include +#include "getopt.h" +#endif + +#include "ftplib.h" + +#if !defined(S_ISDIR) +#define S_ISDIR(m) ((m&S_IFMT) == S_IFDIR) +#endif + +/* exit values */ +#define EX_SYNTAX 2 /* command syntax errors */ +#define EX_NETDB 3 /* network database errors */ +#define EX_CONNECT 4 /* network connect errors */ +#define EX_LOGIN 5 /* remote login errors */ +#define EX_REMCMD 6 /* remote command errors */ +#define EX_SYSERR 7 /* system call errors */ + +#define FTP_SEND 1 /* send files */ +#define FTP_GET 2 /* retreive files */ +#define FTP_DIR 3 /* verbose directory */ +#define FTP_RM 4 /* delete files */ +#define FTP_LIST 5 /* terse directory */ + +#define DIRBUF_SIZE 1024 /* for wildcard processing */ + +#if defined(__UINT64_MAX) +#if defined(PRIu64) +#define PRIFSZ PRIu64 +#else +#if ULONG_MAX == __UINT32_MAX +#define PRIFSZ "llu" +#else +#define PRIFSZ "lu" +#endif +#endif +#else +#ifdef PRIu32 +#define PRIFSZ PRIu32 +#else +#define PRIFSZ "u" +#endif +#endif + +static int logged_in = 0; +static char *host = NULL; +static char *user = NULL; +static char *pass = NULL; +static char mode = 'I'; +static int action = 0; +static char *invocation; +static netbuf *conn = NULL; +static int wildcard = 0; +static int strippath = 0; + +void usage(void) +{ + printf( + "usage: %s \n" + "\t cmd = send | get | dir | list | rm\n" + "\t[ -l user [ -p pass ] ] defaults to anonymous/user@hostname\n" + "\t[\n" + "\t [ -v level ] debug level\n" + "\t [ -r rootpath ] chdir path\n" + "\t [ -m umask ] umask for created files\n" + "\t [ -a | -i ] ] ascii/image transfer file\n" + "\t [ -w ] toggle wildcard mode\n" + "\t [ -s cmd ] issue a SITE command\n" + "\t [ -b ] toggles stripping of path from filename on send\n" + "\t [ file ] file spec for directory or file to transfer\n" + "\t]...\n\n" + "If no files are specified on command line, the program\n" + "will read file names from stdin.\n", invocation); +} + +void ftp_connect(void) +{ + if (conn) + return; + if (host == NULL) + { + fprintf(stderr,"Host name not specified\n"); + usage(); + exit(EX_SYNTAX); + } + if (!logged_in) + { + if (user == NULL) + { + user = "anonymous"; + if (pass == NULL) + { + char *u,h[64]; + u = getenv("USER"); + if (gethostname(h,64) < 0) + { + perror("gethostname"); + exit(EX_NETDB); + } + if ((u != NULL) && (h != NULL)) + { + static char xxx[256]; + sprintf(xxx,"%s@%s",u,h); + pass = xxx; + } + } + } + else if (pass == NULL) +#if defined(_WIN32) || defined(VMS) + exit(EX_LOGIN); +#else + if ((pass = getpass("Password: ")) == NULL) + exit(EX_SYSERR); +#endif + if (!FtpConnect(host,&conn)) + { + fprintf(stderr,"Unable to connect to node %s\n",host); + exit(EX_CONNECT); + } + if (!FtpLogin(user,pass,conn)) + { + fprintf(stderr,"Login failure\n%s",FtpLastResponse(conn)); + exit(EX_LOGIN); + } + logged_in++; + } +} + +void change_directory(char *root) +{ + ftp_connect(); + if (!FtpChdir(root, conn)) + { + fprintf(stderr,"Change directory failed\n%s",FtpLastResponse(conn)); + exit(EX_REMCMD); + } +} + +void site_cmd(char *cmd) +{ + ftp_connect(); + if (!FtpSite( cmd, conn )) + { + fprintf(stderr,"SITE command failed\n%s", FtpLastResponse(conn)); + exit(EX_REMCMD); + } +} + +struct REMFILE { + struct REMFILE *next; + fsz_t fsz; + char *fnm; +}; + +static int log_progress(netbuf *ctl, fsz_t xfered, void *arg) +{ + struct REMFILE *f = (struct REMFILE *) arg; + if ( f->fsz ) + { + double pct = (xfered * 100.0) / f->fsz; + printf("%s %5.2f%% %" PRIFSZ "\r", f->fnm, pct, xfered); + } + else + { + printf("%s %" PRIFSZ "\r", f->fnm, xfered); + } + fflush(stdout); + return 1; +} + +void process_file(char *fnm) +{ + int sts=0; + fsz_t fsz; + struct REMFILE *filelist = NULL; + struct REMFILE rem; + + ftp_connect(); + FtpClearCallback(conn); + if ((action == FTP_SEND) || (action == FTP_GET) || (action == FTP_RM)) + { + if (action == FTP_SEND) + { + struct stat info; + if (stat(fnm,&info) == -1) + { + perror(fnm); + return; + } + if (S_ISDIR(info.st_mode)) + { + if (!FtpMkdir(fnm, conn)) + fprintf(stderr,"mkdir %s failed\n%s",fnm,FtpLastResponse(conn)); + else + if (ftplib_debug) + fprintf(stderr,"Directory %s created\n",fnm); + return; + } + fsz = info.st_size; + } + else + { + if (!wildcard) + { + struct REMFILE *f; + f = (struct REMFILE *) malloc(sizeof(struct REMFILE)); + memset(f,0,sizeof(struct REMFILE)); + f->next = filelist; + filelist = f; + f->fnm = strdup(fnm); + } else { + netbuf *dir; + char *buf; + if (!FtpAccess(fnm, FTPLIB_DIR, FTPLIB_ASCII, conn, &dir)) + { + fprintf(stderr,"error requesting directory of %s\n%s\n", + fnm, FtpLastResponse(conn)); + return; + } + buf = malloc(DIRBUF_SIZE); + while (FtpRead(buf, DIRBUF_SIZE, dir) > 0) + { + struct REMFILE *f; + char *p; + f = (struct REMFILE *) malloc(sizeof(struct REMFILE)); + memset(f,0,sizeof(struct REMFILE)); + f->next = filelist; + p = strchr(buf,'\n'); + if (p) + *p = '\0'; + f->fnm = strdup(buf); + filelist = f; + } + free(buf); + FtpClose(dir); + } + } + } + switch (action) + { + case FTP_DIR : + sts = FtpDir(NULL, fnm, conn); + break; + case FTP_LIST : + sts = FtpNlst(NULL, fnm, conn); + break; + case FTP_SEND : + rem.next = NULL; + rem.fnm = fnm; + rem.fsz = fsz; + fsz /= 100; + if (fsz > 100000) + fsz = 100000; + if (ftplib_debug && fsz) + { + FtpCallbackOptions opt; + opt.cbFunc = log_progress; + opt.cbArg = &rem; + opt.idleTime = 1000; + opt.bytesXferred = fsz; + FtpSetCallback(&opt,conn); + } + sts = FtpPut(fnm,strippath ? basename(fnm) : fnm,mode,conn); + if (ftplib_debug && sts) + printf("%s sent\n",fnm); + break; + case FTP_GET : + while (filelist) + { + struct REMFILE *f = filelist; + filelist = f->next; +#if defined(__UINT64_MAX) + if (!FtpSizeLong(f->fnm, &fsz, mode, conn)) +#else + if (!FtpSize(f->fnm, &fsz, mode, conn)) +#endif + fsz = 0; + f->fsz = fsz; + fsz /= 100; + if (fsz > 100000) + fsz = 100000; + if ( fsz == 0 ) + fsz = 32768; + if (ftplib_debug) + { + FtpCallbackOptions opt; + opt.cbFunc = log_progress; + opt.cbArg = f; + opt.idleTime = 1000; + opt.bytesXferred = fsz; + FtpSetCallback(&opt,conn); + } + sts = FtpGet(f->fnm,f->fnm,mode,conn); + if (ftplib_debug && sts) + printf("%s retrieved\n",f->fnm); + free(f->fnm); + free(f); + } + break; + case FTP_RM : + while (filelist) + { + struct REMFILE *f = filelist; + filelist = f->next; + sts = FtpDelete(f->fnm,conn); + if (ftplib_debug && sts) + printf("%s deleted\n", f->fnm); + free(f->fnm); + free(f); + } + break; + } + if (!sts) + printf("ftp error\n%s\n",FtpLastResponse(conn)); + return; +} + +void set_umask(char *m) +{ + char buf[80]; + sprintf(buf,"umask %s", m); + ftp_connect(); + FtpSite(buf, conn); +} + +int main(int argc, char *argv[]) +{ + int files_processed = 0; + int opt; + + invocation = argv[0]; + optind = 1; + if (strstr(argv[0],"send") != NULL) + action = FTP_SEND; + else if (strstr(argv[0],"get") != NULL) + action = FTP_GET; + else if (strstr(argv[0],"dir") != NULL) + action = FTP_DIR; + else if (strstr(argv[0],"list") != NULL) + action = FTP_LIST; + else if (strstr(argv[0],"rm") != NULL) + action = FTP_RM; + if ((action == 0) && (argc > 2)) + { + if ( argc < 3 ) /* command + site */ + { + usage(); + exit( EX_SYNTAX ); + } + if (strcmp(argv[1],"send") == 0) + action = FTP_SEND; + else if (strcmp(argv[1],"get") == 0) + action = FTP_GET; + else if (strcmp(argv[1],"dir") == 0) + action = FTP_DIR; + else if (strcmp(argv[1],"list") == 0) + action = FTP_LIST; + else if (strcmp(argv[1],"rm") == 0) + action = FTP_RM; + if (action) + optind++; + } + if (action == 0) + { + usage(); + exit(EX_SYNTAX); + } + + FtpInit(); + + // while (argv[optind] != NULL) + while ( optind < argc ) + { + if (argv[optind][0] != '-') + { + if (host == NULL) + host = argv[optind++]; + else + { + process_file(argv[optind++]); + files_processed++; + } + continue; + } + opt = getopt(argc,argv,"abil:m:p:r:s:v:w"); + switch (opt) + { + case '?' : + fprintf(stderr,"Invalid option: %c\n", opt); + usage(); + exit(EX_SYNTAX); + case ':' : + usage(); + exit(EX_SYNTAX); + case 'a' : mode = 'A'; break; + case 'b' : strippath = !strippath; break; + case 'i' : mode = 'I'; break; + case 'l' : user = optarg; break; + case 'm' : set_umask(optarg); break; + case 'p' : pass = optarg; break; + case 'r' : change_directory(optarg); break; + case 's' : site_cmd(optarg); break; + case 'v' : + if (opt == ':') + ftplib_debug++; + else + ftplib_debug = atoi(optarg); + break; + case 'w' : wildcard = !wildcard; break; + default : + usage(); + exit(EX_SYNTAX); + } + } + + if (files_processed == 0) + { + ftp_connect(); + if ((action == FTP_DIR) || (action == FTP_LIST)) + process_file(NULL); + else + { + char fnm[256]; + do + { + char *nl; + if (isatty(fileno(stdin))) + printf("file> "); + if (fgets(fnm, sizeof(fnm), stdin) == NULL) + break; + if ((nl = strchr(fnm,'\n')) != NULL) + *nl = '\0'; + process_file(fnm); + } + while (1); + } + } + if (conn) + FtpClose(conn); + return 0; +} diff --git a/deps/ftplib-4.0-1/src/qftp.opt b/deps/ftplib-4.0-1/src/qftp.opt new file mode 100644 index 0000000..cbc9dfb --- /dev/null +++ b/deps/ftplib-4.0-1/src/qftp.opt @@ -0,0 +1,2 @@ +qftp.obj +ftplib.exe/share diff --git a/deps/ftplib-4.0-1/src/qftp_alpha.opt b/deps/ftplib-4.0-1/src/qftp_alpha.opt new file mode 100644 index 0000000..82e00bf --- /dev/null +++ b/deps/ftplib-4.0-1/src/qftp_alpha.opt @@ -0,0 +1,2 @@ +qftp_alpha.obj +ftplib_alpha.exe/share diff --git a/deps/ftplib-4.0-1/src/qftp_ia64.opt b/deps/ftplib-4.0-1/src/qftp_ia64.opt new file mode 100644 index 0000000..3d9680d --- /dev/null +++ b/deps/ftplib-4.0-1/src/qftp_ia64.opt @@ -0,0 +1,2 @@ +qftp_ia64.obj +ftplib_ia64.exe/share