From this end it looks like you're doing a lot. Below is what I see (71 of these in 55 sec). Lucky seems to be working. There have been no changes lately. I have never used SYNC so I can't even guess what's going on.
As I said, I never used SYNC before. According to the help, if you start with nothing, and specify "/C" you'll end up with nothing:
/C Copy files only if the destination file exists and is older than the source file. This option is useful for updating the files in one directory from those in another without copying any files not already in the target directory.
And if the help is correct, I should not have gotten empty subdirectories (having used /F /S) ... but I did get them.
And (I'm doing it now) ... if I leave out the "/C" it **does** populate the directories with files.
I brought up the /F issue when the same option was added to COPY many years ago. Rex replied that if the source is FTP and the target is local, the operation is not feasible, the empty target must be created before the source can be tested whether or not it is empty of matching files; excessive overhead to remove the empty target directory.
I think the equivalent of my alias below, which I use after copying data from an FTP site, could be executed by COPY, MOVE and SYNC when the /F options is present: *del/qyxs/net/a:d .
It would seem reasonable that CWD expects an argument. PWD gets you the current directory. From RFC 959,
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.
That's basically what I do, but - to preserve history and to be able to return to an earlier version if other issues exist - I first get the timestamp of the latest file in the previous download, add a small fudge factor (depending on the site), download to an empty new directory, and limit downloads to the date range "later than the fudge factor". The procedure would fail if you built a new version of a previous file BEFORE my previous download, but did not release it until after the download. Never an issue with ftp://jpsoft.com or any other site which uses the POSIX defaults for putting new versions on a server with POSIX file system, the file's apparent modification date I can see is not its true modification date but rather the time it arrived on the server (one of the miscreations of the authors of Unix). Like the date of what is on a photocopy is not the date of what is copied, but when it is copied...
OT: I got a new office today and lucky went from 10 megabit to 1 gigabit. I can see a slight improvement from home when I remote desktop to lucky and a significant improvement when I'm surfing on lucky. Please comment if you notice that the FTP site is quicker.