Scp PureBasic Reference Documentation

Scp

Current Version: 9.5.0.73

An API for SCP over SSH. (SCP is the Secure Copy Protocol.) It is for transferring files or directory trees to or from remote servers. SCP is a simpler protocol than SFTP, and thus the functionality is more limited. However, SCP does not require that an SSH server support the SFTP subsystem. In cases where a server does not allow for SFTP, then SCP is a good choice for file transfer.

Object Creation

obj.i = CkScp::ckCreate()

; Make sure to dispose of the object when finished like this:
CkScp::ckDispose(obj);

Properties

AbortCurrent
Declare.i ckAbortCurrent(obj.i)
Declare setCkAbortCurrent(obj.i, value.i)
Introduced in version 9.5.0.58

When set to 1, causes the currently running method to abort. Methods that always finish quickly (i.e.have no length file operations or network communications) are not affected. If no method is running, then this property is automatically reset to 0 when the next method is called. When the abort occurs, this property is reset to 0. Both synchronous and asynchronous method calls can be aborted. (A synchronous method call could be aborted by setting this property from a separate thread.)

top
DebugLogFilePath
Declare.s ckDebugLogFilePath(obj.i)
Declare setCkDebugLogFilePath(obj.i, value.s)

If set to a file path, causes each Chilkat method or property call to automatically append it's LastErrorText to the specified log file. The information is appended such that if a hang or crash occurs, it is possible to see the context in which the problem occurred, as well as a history of all Chilkat calls up to the point of the problem. The VerboseLogging property can be set to provide more detailed information.

This property is typically used for debugging the rare cases where a Chilkat method call hangs or generates an exception that halts program execution (i.e. crashes). A hang or crash should generally never happen. The typical causes of a hang are:

  1. a timeout related property was set to 0 to explicitly indicate that an infinite timeout is desired,
  2. the hang is actually a hang within an event callback (i.e. it is a hang within the application code), or
  3. there is an internal problem (bug) in the Chilkat code that causes the hang.

top
LastErrorHtml
Declare.s ckLastErrorHtml(obj.i) ; (read-only)

Provides information in HTML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastErrorText
Declare.s ckLastErrorText(obj.i) ; (read-only)

Provides information in plain-text format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastErrorXml
Declare.s ckLastErrorXml(obj.i) ; (read-only)

Provides information in XML format about the last method/property called. If a method call returns a value indicating failure, or behaves unexpectedly, examine this property to get more information.

top
LastMethodSuccess
Declare.i ckLastMethodSuccess(obj.i)
Declare setCkLastMethodSuccess(obj.i, value.i)
Introduced in version 9.5.0.52

Indicate whether the last method call succeeded or failed. A value of 1 indicates success, a value of 0 indicates failure. This property is automatically set for method calls. It is not modified by property accesses. The property is automatically set to indicate success for the following types of method calls:

  • Any method that returns a string.
  • Any method returning a Chilkat object, binary bytes, or a date/time.
  • Any method returning a standard boolean status value where success = 1 and failure = 0.
  • Any method returning an integer where failure is defined by a return value less than zero.

Note: Methods that do not fit the above requirements will always set this property equal to 1. For example, a method that returns no value (such as a "void" in C++) will technically always succeed.

top
SyncedFiles
Declare.s ckSyncedFiles(obj.i)
Declare setCkSyncedFiles(obj.i, value.s)
Introduced in version 9.5.0.51

The paths of the files uploaded or downloaded in the last call to SyncUploadTree or SyncDownloadTree. The paths are listed one per line. In both cases (for upload and download) each line contains the full local file path (not the remote path).

More Information and Examples
top
SyncMustMatch
Declare.s ckSyncMustMatch(obj.i)
Declare setCkSyncMustMatch(obj.i, value.s)
Introduced in version 9.5.0.51

Can contain a wildcarded list of filename patterns separated by semicolons. For example, "*.xml; *.txt; *.csv". If set, the SyncTreeUpload and SyncTreeDownload methods will only transfer files having a filename that matches any one of these patterns.

top
SyncMustMatchDir
Declare.s ckSyncMustMatchDir(obj.i)
Declare setCkSyncMustMatchDir(obj.i, value.s)
Introduced in version 9.5.0.58

Can contain a wildcarded list of directory name patterns separated by semicolons. For example, "a*; b*; c*". If set, the SyncTreeUpload and SyncTreeDownload methods will only traverse into a directory that matches any one of these patterns.

top
SyncMustNotMatch
Declare.s ckSyncMustNotMatch(obj.i)
Declare setCkSyncMustNotMatch(obj.i, value.s)
Introduced in version 9.5.0.51

Can contain a wildcarded list of filename patterns separated by semicolons. For example, "*.xml; *.txt; *.csv". If set, the SyncTreeUpload and SyncTreeDownload methods will not transfer files having a filename that matches any one of these patterns.

More Information and Examples
top
SyncMustNotMatchDir
Declare.s ckSyncMustNotMatchDir(obj.i)
Declare setCkSyncMustNotMatchDir(obj.i, value.s)
Introduced in version 9.5.0.58

Can contain a wildcarded list of directory name patterns separated by semicolons. For example, "a*; b*; c*". If set, the SyncTreeUpload and SyncTreeDownload methods will not traverse into a directory that matches any one of these patterns.

top
VerboseLogging
Declare.i ckVerboseLogging(obj.i)
Declare setCkVerboseLogging(obj.i, value.i)

If set to 1, then the contents of LastErrorText (or LastErrorXml, or LastErrorHtml) may contain more verbose information. The default value is 0. Verbose logging should only be used for debugging. The potentially large quantity of logged information may adversely affect peformance.

top
Version
Declare.s ckVersion(obj.i) ; (read-only)

Version of the component/library, such as "9.5.0.63"

top

Methods

DownloadBinaryEncoded
Declare.s ckDownloadBinaryEncoded(obj.i, remotePath.s, encoding.s)
Introduced in version 9.5.0.51

Downloads a file from the SSH server returns the contents in an encoded string (using an encoding such as base64).

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

top
DownloadBinaryEncodedAsync (1)
Declare.i ckDownloadBinaryEncodedAsync(obj.i, remotePath.s, encoding.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the DownloadBinaryEncoded method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
DownloadFile
Declare.i ckDownloadFile(obj.i, remotePath.s, localPath.s)
Introduced in version 9.5.0.51

Downloads a file from the remote SSH server to the local filesystem.

Returns 1 for success, 0 for failure.

top
DownloadFileAsync (1)
Declare.i ckDownloadFileAsync(obj.i, remotePath.s, localPath.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the DownloadFile method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
DownloadString
Declare.s ckDownloadString(obj.i, remotePath.s, charset.s)
Introduced in version 9.5.0.51

Downloads a text file from the SSH server and returns the contents as a string.

Returns an empty string on failure. Use the LastMethodSuccess property to check for success.

More Information and Examples
top
DownloadStringAsync (1)
Declare.i ckDownloadStringAsync(obj.i, remotePath.s, charset.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the DownloadString method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SaveLastError
Declare.i ckSaveLastError(obj.i, path.s)

Saves the last-error information (the contents of LastErrorXml) to an XML formatted file.

Returns 1 for success, 0 for failure.

top
SyncTreeDownload
Declare.i ckSyncTreeDownload(obj.i, remoteRoot.s, localRoot.s, mode.l, bRecurse.l)
Introduced in version 9.5.0.51

Downloads files from the SSH server to a local directory tree. Synchronization modes include:

mode=0: Download all files
mode=1: Download all files that do not exist on the local filesystem.
mode=2: Download newer or non-existant files.
mode=3: Download only newer files. If a file does not already exist on the local filesystem, it is not downloaded from the server.
mode=5: Download only missing files or files with size differences.
mode=6: Same as mode 5, but also download newer files.

Returns 1 for success, 0 for failure.

More Information and Examples
top
SyncTreeDownloadAsync (1)
Declare.i ckSyncTreeDownloadAsync(obj.i, remoteRoot.s, localRoot.s, mode.l, bRecurse.l)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the SyncTreeDownload method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
SyncTreeUpload
Declare.i ckSyncTreeUpload(obj.i, localBaseDir.s, remoteBaseDir.s, mode.l, bRecurse.l)
Introduced in version 9.5.0.51

Uploads a directory tree from the local filesystem to the SSH server. Synchronization modes include:

mode=0: Upload all files
mode=1: Upload all files that do not exist on the FTP server.
mode=2: Upload newer or non-existant files.
mode=3: Upload only newer files. If a file does not already exist on the FTP server, it is not uploaded.
mode=4: transfer missing files or files with size differences.
mode=5: same as mode 4, but also newer files.

Returns 1 for success, 0 for failure.

top
SyncTreeUploadAsync (1)
Declare.i ckSyncTreeUploadAsync(obj.i, localBaseDir.s, remoteBaseDir.s, mode.l, bRecurse.l)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the SyncTreeUpload method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
UploadBinaryEncoded
Declare.i ckUploadBinaryEncoded(obj.i, remotePath.s, encodedData.s, encoding.s)
Introduced in version 9.5.0.51

Uploads the binary data to a file on the remote SSH server. The binary data is passed in encoded string representation (such as base64, or hex).

Returns 1 for success, 0 for failure.

top
UploadBinaryEncodedAsync (1)
Declare.i ckUploadBinaryEncodedAsync(obj.i, remotePath.s, encodedData.s, encoding.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the UploadBinaryEncoded method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
UploadFile
Declare.i ckUploadFile(obj.i, localPath.s, remotePath.s)
Introduced in version 9.5.0.51

Uploads a file from the local filesystem to the remote SSH server.

Returns 1 for success, 0 for failure.

top
UploadFileAsync (1)
Declare.i ckUploadFileAsync(obj.i, localPath.s, remotePath.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the UploadFile method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
UploadString
Declare.i ckUploadString(obj.i, remotePath.s, textData.s, charset.s)
Introduced in version 9.5.0.51

Uploads the contents of a string to a file on the remote SSH server.

Returns 1 for success, 0 for failure.

More Information and Examples
top
UploadStringAsync (1)
Declare.i ckUploadStringAsync(obj.i, remotePath.s, textData.s, charset.s)
Introduced in version 9.5.0.51

Creates an asynchronous task to call the UploadString method with the arguments provided. (Async methods are available starting in Chilkat v9.5.0.52.)

Returns 0 on failure

top
UseSsh
Declare.i ckUseSsh(obj.i, sshConnection.i)
Introduced in version 9.5.0.51

Uses the SSH connection of sshConnection for the SCP transfers. All of the connection and socket related properties, proxy properites, timeout properties, session log, etc. set on the SSH object apply to the SCP methods (because internally it is the SSH object that is used to do the work of the file transfers).

Note: There is no UnlockComponent method in the SCP class because it is the SSH object that must be unlocked. When the SSH object is not unlocked, this method will return 0 to indicate failure.

Returns 1 for success, 0 for failure.

top