Inherits QNetworkProtocol.
This class provides two different interfaces: one is the QNetworkProtocol interface that allows you to use FTP through the QUrlOperator abstraction. The other is a direct interface to FTP that gives you lower-level access to the FTP protocol for finer control. Using the direct interface you can also execute arbitrary FTP commands.
Don't mix the two interfaces, since the behavior is not well-defined.
If you want to use QFtp with the QNetworkProtocol interface, you do not use it directly, but rather through a QUrlOperator, for example:
QUrlOperator op( "ftp://ftp.trolltech.com" );
op.listChildren(); // Asks the server to provide a directory listing
This code will only work if the QFtp class is registered; to register the class, you must call qInitNetworkProtocols() before using a QUrlOperator with QFtp.
The rest of this descrption describes the direct interface to FTP.
The class works asynchronously, so there are no blocking functions. If an operation cannot be executed immediately, the function will still return straight away and the operation will be scheduled for later execution. The results of scheduled operations are reported via signals. This approach depends on the event loop being in operation.
The operations that can be scheduled (they are called "commands" in the rest of the documentation) are the following: connectToHost(), login(), close(), list(), cd(), get(), put(), remove(), mkdir(), rmdir(), rename() and rawCommand().
All of these commands return a unique identifier that allows you to keep track of the command that is currently being executed. When the execution of a command starts, the commandStarted() signal with the command's identifier is emitted. When the command is finished, the commandFinished() signal is emitted with the command's identifier and a bool that indicates whether the command finished with an error.
In some cases, you might want to execute a sequence of commands, e.g. if you want to connect and login to a FTP server. This is simply achieved:
QFtp *ftp = new QFtp( this ); // this is an optional QObject parent
ftp->connectToHost( "ftp.trolltech.com" );
ftp->login();
In this case two FTP commands have been scheduled. When the last scheduled command has finished, a done() signal is emitted with a bool argument that tells you whether the sequence finished with an error.
If an error occurs during the execution of one of the commands in a sequence of commands, all the pending commands (i.e. scheduled, but not yet executed commands) are cleared and no signals are emitted for them.
Some commands, e.g. list(), emit additional signals to report their results.
Example: If you want to download the INSTALL file from Trolltech's FTP server, you would write this:
ftp->connectToHost( "ftp.trolltech.com" ); // id == 1
ftp->login(); // id == 2
ftp->cd( "qt" ); // id == 3
ftp->get( "INSTALL" ); // id == 4
ftp->close(); // id == 5
For this example the following sequence of signals is emitted (with small variations, depending on network traffic, etc.):
start( 1 )
stateChanged( HostLookup )
stateChanged( Connecting )
stateChanged( Connected )
finished( 1, FALSE )
start( 2 )
stateChanged( LoggedIn )
finished( 2, FALSE )
start( 3 )
finished( 3, FALSE )
start( 4 )
dataTransferProgress( 0, 3798 )
dataTransferProgress( 2896, 3798 )
readyRead()
dataTransferProgress( 3798, 3798 )
readyRead()
finished( 4, FALSE )
start( 5 )
stateChanged( Closing )
stateChanged( Unconnected )
finished( 5, FALSE )
done( FALSE )
The dataTransferProgress() signal in the above example is useful if you want to show a progressbar to inform the user about the progress of the download. The readyRead() signal tells you that there is data ready to be read. The amount of data can be queried then with the bytesAvailable() function and it can be read with the readBlock() or readAll() function.
If the login fails for the above example, the signals would look like this:
start( 1 )
stateChanged( HostLookup )
stateChanged( Connecting )
stateChanged( Connected )
finished( 1, FALSE )
start( 2 )
finished( 2, TRUE )
done( TRUE )
You can then get details about the error with the error() and errorString() functions.
The functions currentId() and currentCommand() provide more information about the currently executing command.
The functions hasPendingCommands() and clearPendingCommands() allow you to query and clear the list of pending commands.
The safest and easiest way to use the FTP protocol is to use QUrlOperator() or the FTP commands described above. If you are an experienced network programmer and want to have complete control you can use rawCommand() to execute arbitrary FTP commands.
See also Qt Network Documentation, QNetworkProtocol, QUrlOperator, QHttp, and Input/Output and Networking.
See also stateChanged() and state().
If there is an unfinished command (i.e. a command for which the commandStarted() signal has been emitted, but for which the commandFinished() signal has not been emitted), this function sends an ABORT command to the server. When the server replies that the command is aborted, the commandFinished() signal with the error argument set to TRUE is emitted for the command. Due to timing issues, it is possible that the command had already finished before the abort request reached the server, in which case, the commandFinished() signal is emitted with the error argument set to FALSE.
For all other commands that are affected by the abort(), no signals are emitted.
If you don't start further FTP commands directly after the abort(), there won't be any scheduled commands and the done() signal is emitted.
Warning: Some FTP servers, for example the BSD FTP daemon (version 0.3), wrongly return a positive reply even when an abort has occurred. For these servers the commandFinished() signal has its error flag set to FALSE, even though the command did not complete successfully.
See also clearPendingCommands().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also get(), readyRead(), readBlock(), and readAll().
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also hasPendingCommands() and abort().
The stateChanged() signal is emitted when the state of the connecting process changes, e.g. to Closing, then Unconnected.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also stateChanged(), commandStarted(), and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also commandStarted(), done(), error(), and errorString().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also commandFinished() and done().
Example: network/ftpclient/ftpmainwindow.ui.h.
The stateChanged() signal is emitted when the state of the connecting process changes, e.g. to HostLookup, then Connecting, then Connected.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also stateChanged(), commandStarted(), and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also currentId().
Example: network/ftpclient/ftpmainwindow.ui.h.
This function can be used to delete the QIODevice in the slot connected to the commandFinished() signal.
See also get() and put().
Example: network/ftpclient/ftpmainwindow.ui.h.
done is the amount of data that has already been transferred and total is the total amount of data to be read or written. It is possible that the QFtp class is not able to determine the total amount of data that should be transferred, in which case total is 0. (If you connect this signal to a QProgressBar, the progress bar shows a busy indicator if the total is 0).
Warning: done and total are not necessarily the size in bytes, since for large files these values might need to be" scaled" to avoid overflow.
See also get(), put(), and QProgressBar::progress.
Example: network/ftpclient/ftpmainwindow.ui.h.
See also commandFinished(), error(), and errorString().
Example: network/ftpclient/ftpmainwindow.ui.h.
If you start a new command, the error status is reset to NoError.
The error string is often (but not always) the reply from the server, so it is not always possible to translate the string. If the message comes from Qt, the string has already passed through tr().
Example: network/ftpclient/ftpmainwindow.ui.h.
If dev is 0, then the readyRead() signal is emitted when there is data available to read. You can then read the data with the readBlock() or readAll() functions.
If dev is not 0, the data is written directly to the device dev. Make sure that the dev pointer is valid for the duration of the operation (it is safe to delete it when the commandFinished() signal is emitted). In this case the readyRead() signal is not emitted and you cannot read data with the readBlock() or readAll() functions.
If you don't read the data immediately it becomes available, i.e. when the readyRead() signal is emitted, it is still available until the next command is started.
For example, if you want to present the data to the user as soon as there is something available, connect to the readyRead() signal and read the data immediately. On the other hand, if you only want to work with the complete data, you can connect to the commandFinished() signal and read the data when the get() command is finished.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also readyRead(), dataTransferProgress(), commandStarted(), and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
The command that is being executed is not considered as a scheduled command.
See also clearPendingCommands(), currentId(), and currentCommand().
The listInfo() signal is emitted for each directory entry found.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also listInfo(), commandStarted(), and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also list().
Example: network/ftpclient/ftpmainwindow.ui.h.
The stateChanged() signal is emitted when the state of the connecting process changes, e.g. to LoggedIn.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
Make sure that the dev pointer is valid for the duration of the operation (it is safe to delete it when the commandFinished() is emitted).
Example: network/ftpclient/ftpmainwindow.ui.h.
Writes the data data to the file called file on the server. The progress of the upload is reported by the dataTransferProgress() signal.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also dataTransferProgress(), commandStarted(), and commandFinished().
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also rawCommandReply(), commandStarted(), and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also rawCommand().
Example: network/ftpclient/ftpmainwindow.ui.h.
See also get(), readyRead(), bytesAvailable(), and readBlock().
See also get(), readyRead(), bytesAvailable(), and readAll().
If you specify a device as the second argument in the get() command, this signal is not emitted; instead the data is written directly to the device.
You can read the data with the readAll() or readBlock() functions.
This signal is useful if you want to process the data in chunks as soon as it becomes available. If you are only interested in the complete data, just connect to the commandFinished() signal and read the data then instead.
See also get(), readBlock(), readAll(), and bytesAvailable().
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
Example: network/ftpclient/ftpmainwindow.ui.h.
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
The function does not block and returns immediately. The command is scheduled, and its execution is performed asynchronously. The function returns a unique identifier which is passed by commandStarted() and commandFinished().
When the command is started the commandStarted() signal is emitted. When it is finished the commandFinished() signal is emitted.
See also commandStarted() and commandFinished().
See also State and stateChanged().
Example: network/ftpclient/ftpmainwindow.ui.h.
It is usually emitted in response to a connectToHost() or close() command, but it can also be emitted "spontaneously", e.g. when the server closes the connection unexpectedly.
See also connectToHost(), close(), state(), and State.
Example: network/ftpclient/ftpmainwindow.ui.h.