diff --git a/deps/ftplib-4.0-1/CHANGES b/deps/ftplib-4.0-1/CHANGES deleted file mode 100644 index 1cd99eb..0000000 --- a/deps/ftplib-4.0-1/CHANGES +++ /dev/null @@ -1,191 +0,0 @@ -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 deleted file mode 100644 index 1a630a2..0000000 --- a/deps/ftplib-4.0-1/LICENSE +++ /dev/null @@ -1,171 +0,0 @@ -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 deleted file mode 100644 index 519c2a4..0000000 --- a/deps/ftplib-4.0-1/README.ftplib-4.0-1 +++ /dev/null @@ -1,18 +0,0 @@ -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 deleted file mode 100644 index 804936a..0000000 --- a/deps/ftplib-4.0-1/README.qftp +++ /dev/null @@ -1,41 +0,0 @@ -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 deleted file mode 100644 index 5c9f11a..0000000 --- a/deps/ftplib-4.0-1/RFC959.txt +++ /dev/null @@ -1,3933 +0,0 @@ - - -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 deleted file mode 100644 index fd73fff..0000000 --- a/deps/ftplib-4.0-1/additional_rfcs +++ /dev/null @@ -1,2 +0,0 @@ -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 deleted file mode 100644 index 3ce3127..0000000 --- a/deps/ftplib-4.0-1/html/FtpAccess.html +++ /dev/null @@ -1,42 +0,0 @@ - - - -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 deleted file mode 100644 index 4224590..0000000 --- a/deps/ftplib-4.0-1/html/FtpCDUp.html +++ /dev/null @@ -1,26 +0,0 @@ - - - -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 deleted file mode 100644 index e033910..0000000 --- a/deps/ftplib-4.0-1/html/FtpChdir.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index 61b0c56..0000000 --- a/deps/ftplib-4.0-1/html/FtpClearCallback.html +++ /dev/null @@ -1,27 +0,0 @@ - - - -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 deleted file mode 100644 index c2f7565..0000000 --- a/deps/ftplib-4.0-1/html/FtpClose.html +++ /dev/null @@ -1,32 +0,0 @@ - - - -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 deleted file mode 100644 index f590a8a..0000000 --- a/deps/ftplib-4.0-1/html/FtpConnect.html +++ /dev/null @@ -1,35 +0,0 @@ - - - -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 deleted file mode 100644 index 03a14a9..0000000 --- a/deps/ftplib-4.0-1/html/FtpDelete.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index bccccc5..0000000 --- a/deps/ftplib-4.0-1/html/FtpDir.html +++ /dev/null @@ -1,37 +0,0 @@ - - - -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 deleted file mode 100644 index 6664ec1..0000000 --- a/deps/ftplib-4.0-1/html/FtpGet.html +++ /dev/null @@ -1,34 +0,0 @@ - - - -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 deleted file mode 100644 index 6af86c8..0000000 --- a/deps/ftplib-4.0-1/html/FtpInit.html +++ /dev/null @@ -1,22 +0,0 @@ - - - -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 deleted file mode 100644 index 24c6512..0000000 --- a/deps/ftplib-4.0-1/html/FtpLastResponse.html +++ /dev/null @@ -1,31 +0,0 @@ - - - -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 deleted file mode 100644 index cff609e..0000000 --- a/deps/ftplib-4.0-1/html/FtpLogin.html +++ /dev/null @@ -1,30 +0,0 @@ - - - -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 deleted file mode 100644 index cd3a9c6..0000000 --- a/deps/ftplib-4.0-1/html/FtpMkdir.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index 34af4d9..0000000 --- a/deps/ftplib-4.0-1/html/FtpModDate.html +++ /dev/null @@ -1,36 +0,0 @@ - - - -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 deleted file mode 100644 index 88b87c8..0000000 --- a/deps/ftplib-4.0-1/html/FtpNlst.html +++ /dev/null @@ -1,33 +0,0 @@ - - - -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 deleted file mode 100644 index da22c7b..0000000 --- a/deps/ftplib-4.0-1/html/FtpOptions.html +++ /dev/null @@ -1,63 +0,0 @@ - - - -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 deleted file mode 100644 index a3a7e69..0000000 --- a/deps/ftplib-4.0-1/html/FtpPut.html +++ /dev/null @@ -1,34 +0,0 @@ - - - -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 deleted file mode 100644 index 8ac927b..0000000 --- a/deps/ftplib-4.0-1/html/FtpPwd.html +++ /dev/null @@ -1,30 +0,0 @@ - - - -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 deleted file mode 100644 index 32b2485..0000000 --- a/deps/ftplib-4.0-1/html/FtpQuit.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index fa7519d..0000000 --- a/deps/ftplib-4.0-1/html/FtpRead.html +++ /dev/null @@ -1,34 +0,0 @@ - - - -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 deleted file mode 100644 index d91c9d6..0000000 --- a/deps/ftplib-4.0-1/html/FtpRename.html +++ /dev/null @@ -1,30 +0,0 @@ - - - -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 deleted file mode 100644 index a81badf..0000000 --- a/deps/ftplib-4.0-1/html/FtpRmdir.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index 6fe63e9..0000000 --- a/deps/ftplib-4.0-1/html/FtpSetCallback.html +++ /dev/null @@ -1,78 +0,0 @@ - - - -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 deleted file mode 100644 index 4649a12..0000000 --- a/deps/ftplib-4.0-1/html/FtpSite.html +++ /dev/null @@ -1,28 +0,0 @@ - - - -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 deleted file mode 100644 index fed0c72..0000000 --- a/deps/ftplib-4.0-1/html/FtpSize.html +++ /dev/null @@ -1,38 +0,0 @@ - - - -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 deleted file mode 100644 index 80d0c7b..0000000 --- a/deps/ftplib-4.0-1/html/FtpSizeLong.html +++ /dev/null @@ -1,40 +0,0 @@ - - - -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 deleted file mode 100644 index bef3eb9..0000000 --- a/deps/ftplib-4.0-1/html/FtpSysType.html +++ /dev/null @@ -1,31 +0,0 @@ - - - -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 deleted file mode 100644 index 937cab0..0000000 --- a/deps/ftplib-4.0-1/html/FtpWrite.html +++ /dev/null @@ -1,33 +0,0 @@ - - - -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 deleted file mode 100644 index 9419164..0000000 --- a/deps/ftplib-4.0-1/html/doc.css +++ /dev/null @@ -1,29 +0,0 @@ -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 deleted file mode 100644 index e592890..0000000 --- a/deps/ftplib-4.0-1/html/ftplib.html +++ /dev/null @@ -1,92 +0,0 @@ - - - -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 deleted file mode 100644 index c7072c0..0000000 --- a/deps/ftplib-4.0-1/html/index.html +++ /dev/null @@ -1,39 +0,0 @@ - - - -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 deleted file mode 100644 index ee52d60..0000000 --- a/deps/ftplib-4.0-1/html/qftp.html +++ /dev/null @@ -1,114 +0,0 @@ - - - -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 deleted file mode 100644 index 5a2f373..0000000 --- a/deps/ftplib-4.0-1/src/Makefile +++ /dev/null @@ -1,73 +0,0 @@ -# -# 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 deleted file mode 100644 index 5815684..0000000 --- a/deps/ftplib-4.0-1/src/README +++ /dev/null @@ -1,24 +0,0 @@ -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 deleted file mode 100644 index 9ab9361..0000000 --- a/deps/ftplib-4.0-1/src/descrip.mms +++ /dev/null @@ -1,40 +0,0 @@ -.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 deleted file mode 100644 index c5f35f2..0000000 --- a/deps/ftplib-4.0-1/src/ftplib.c +++ /dev/null @@ -1,1455 +0,0 @@ -/***************************************************************************/ -/* */ -/* 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__) || defined(__sun) -#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 deleted file mode 100644 index 82b90a9..0000000 --- a/deps/ftplib-4.0-1/src/ftplib.h +++ /dev/null @@ -1,120 +0,0 @@ -/***************************************************************************/ -/* */ -/* 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 deleted file mode 100644 index 5838062..0000000 --- a/deps/ftplib-4.0-1/src/ftplib.opt +++ /dev/null @@ -1,8 +0,0 @@ -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 deleted file mode 100644 index 6f287b4..0000000 --- a/deps/ftplib-4.0-1/src/ftplib_alpha.opt +++ /dev/null @@ -1,35 +0,0 @@ -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 deleted file mode 100644 index ef38550..0000000 --- a/deps/ftplib-4.0-1/src/ftplib_ia64.opt +++ /dev/null @@ -1,35 +0,0 @@ -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 deleted file mode 100644 index 99232c2..0000000 --- a/deps/ftplib-4.0-1/src/ftplib_vector.mar +++ /dev/null @@ -1,36 +0,0 @@ - .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 deleted file mode 100644 index eaf31fb..0000000 --- a/deps/ftplib-4.0-1/src/qftp.c +++ /dev/null @@ -1,470 +0,0 @@ -/***************************************************************************/ -/* */ -/* 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 deleted file mode 100644 index cbc9dfb..0000000 --- a/deps/ftplib-4.0-1/src/qftp.opt +++ /dev/null @@ -1,2 +0,0 @@ -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 deleted file mode 100644 index 82e00bf..0000000 --- a/deps/ftplib-4.0-1/src/qftp_alpha.opt +++ /dev/null @@ -1,2 +0,0 @@ -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 deleted file mode 100644 index 3d9680d..0000000 --- a/deps/ftplib-4.0-1/src/qftp_ia64.opt +++ /dev/null @@ -1,2 +0,0 @@ -qftp_ia64.obj -ftplib_ia64.exe/share