New opcode options:
|
Symbol |
Value |
Description |
|
XFTPF_RECURSE |
&h00200000 |
recurse subdirs, with wildcards |
|
The following are mutually exclusive (SFTP only); M=missing, N=newer, S=size. | ||
|
XFTPF_SYNC_ALL |
&h00000000 |
all matching files |
|
XFTPF_SYNC_M |
&h01000000 |
all files that don't exist in dest |
|
XFTPF_SYNC_MN |
&h02000000 |
all files that don't exist in dest, or are newer in source |
|
XFTPF_SYNC_N |
&h03000000 |
only files that exist in both places but are newer in src |
|
XFTPF_SYNC_MS |
&h04000000 |
all files that don't exist in dest or are different size |
|
XFTPF_SYNC_MNS |
&h05000000 |
all files that don't exist in dest or are different size or newer |
|
XFTPF_SYNC_DELM |
&h0F000000 |
with XFTPF_DEL, only remote files not existing locally |
The above opcode options apply only to the SFTP protocol (XTFPF_SFTP), and only come into play when a wildcard is specified in the relevant source argument and the destination is just a directory. The wildcard source argument acts as the first level of filtering on files to be transferred, with further filtering determined by the XFTPF_SYNC_xxx options.
Note that unlike most of the XFTPF_xxx flags, which are coded as unique bits and thus could theoretically be combined in any way, provided it makes functional sense, the XFTPF_SYNC_xxx options are all mutually exclusive—i.e., choose only one. Also note that XFTPF_SYNC_DELM only applies in conjunction with XFTPF_DEL.
When doing wildcard transfers or remote deletions, the status parameter now returns on success the number of files transferred or deleted, rather than just zero. Also, the emsg parameter in that case will contain a list of the files transferred or deleted, delimited by line breaks.
See program FTPTST in SOSLIB:[907,33]