JADE XSD Schema Reference - Operation Copy

• Schema: CopySource, CopySource

This parameter specifies the source of a Copy operation.

The following frequently used settings groups are available:

• CopySourceFragmentRef: references one of the ProtocolFragments, e.g. for transfer by FTP, FTPS, SFTP etc..
• SourceFileOptions: specifies e.g. the Selection of files for transfer.

• Schema: CopySourceFragmentRef, CopySourceFragmentRef

This element references a readable fragment that is used to copy files in a Copy operation.

Any number of reusable Fragments elements can be configured and are distinguished by YADE based on their name attribute.

A subsequent fragment reference element points to the fragment that is used as source in the Copy operation.

• Schema: AlternativeCopySourceFragmentRef, AlternativeCopySourceFragmentRef

Alternative fragements can be specified as a replacement for existing file transfer fragments in case that a connection cannot be established with those fragments.

Alternative fragments can be specified from a range of protocol fragments for use with the source of a file transfer operation without modifying files.

For each fragment type depending on the file transfer protocol in use an alternative fragment type is available.

• Schema: SourceFileOptions, SourceFileOptions

These options apply to the handling of files on a source server. They specify e.g. the Selection of files for Copy and Move operations.

• Schema: CopyTarget, CopyTarget

This parameter specifies the target of a Copy operation.

The following frequently used settings groups are available:

• CopyTargetFragmentRef: references one of the ProtocolFragments, e.g. for transfer by FTP, FTPS, SFTP, to a local target etc..
• TargetFileOptions: specifies e.g. if existing files on the target system should be overwritten.

• Schema: CopyTargetFragmentRef, CopyTargetFragmentRef

This element references a writeable fragment that is used to copy files in a Copy operation.

Any number of reusable Fragments elements can be configured and are distinguished by YADE based on their name attribute.

A subsequent fragment reference element points to the fragment that is used as target in the Copy operation.

• Schema: AlternativeCopyTargetFragmentRef, AlternativeCopyTargetFragmentRef

Alternative fragements can be specified as a replacement for existing file transfer fragments in case that a connection cannot be established with those fragments.

Alternative fragments can be specified from a range of protocol fragments for use with the source or target of a file transfer operation that required modifying files.

For each fragment type depending on the file transfer protocol in use an alternative fragment type is available.

• Schema: Directory, Directory
• Mapping:
  • dir

This parameter is used to specify a directory on one of the involved servers. Directories can be adressed using a folder structure, e.g. /folder1/folder2.

For Windows systems when used with the LocalSource parameter then a Windows path including a drive letter can be specified. For all server systems the standard syntax using can be used which includes forward slashes to separate folder names.

The directory can be set absolute or relative to the working directory, where the working directory depends on the server configuration. If for example a user "test" connects to an SFTP server then this user might have /home/test/ as a working directory. This applies to servers that use the home directory as the working directory. In this case you can use relative and absolute adressing as in

• data
• /home/test/data

• Schema: TargetFileOptions, TargetFileOptions

These options apply to files on a target server. They specify e.g. the Atomicity of a file transfer for Copy and Move operations.

• Schema: TransferOptions, TransferOptions

Transfer options specify the optional behavior of file transfer, e.g. the transactional behavior.

• Schema: BufferSize
• Mapping:
  • buffer_size
  • BufferSize

The maximum size of a data block is defined with this option.

• Schema: Transactional, Transactional
• Mapping:
  • transactional
  • TransactionMode

This parameter specifies whether a transfer should be processed within a single transaction, i.e. either all objects are successfully transferred or none.

Should an error occur during a transfer operation then all transfers will be rolled back.

When specifying the value true then the following applies:

• The AtomicSuffix parameter and AtomicPrefix parameter are used that cause target files to be created with a suffix such as "~" (default) and that causes the respective files to be renamed to their target file name after the transfer of all files has been successfully completed.
• If at least one file out of a set of files cannot be transferred successfully then no files will be renamed, instead the temporarily created files are removed from the target system.
• The parameter remove_files that causes files to be removed after successful transfer will be effective only after all files have been successfully transferred. Otherwise no files will be removed.

• Schema: RetryOnConnectionError, RetryOnConnectionError
• Release:
  • YADE-556 Availability starting with 1.12.13, 1.13.4.

To control reconnect behavior, the YADE has two options:

• RetryCountMax - number of reconnection attempts (for each single file transfer) if there is a connection failure
• RetryInterval - the wait interval between attempts