Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

martin

Re: synchronize and interrupted/killed downloads

Timestamp is set only after the transfer finishes. It's not even technically possible to do it earlier. If you have a different experience, please attach a complete session log file.

To generate log file, use /log=path_to_log_file command-line argument. Submit the log with your post as an attachment. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you may email it to me. You will find my address (if you log in) in my forum profile. Please include link back to this topic in your email. Also note in this topic that you have emailed the log.
yzorg

synchronize and interrupted/killed downloads

When synchronizing locally WinSCP creates the local file with the same timestamp as on the server. This means if WinSCP process is killed (In my case by SSIS/SQL Agent after a timeout) then when run again WinSCP skips the file the second time.

This is even true when -criteria=either is set in an attempt to use file size to retry failed attempts. It looks like time trumps size, even for local sync.

open ftp://anonymous:anonymous@wireless.fcc.gov
cd /pub/uls/daily

# does not retry interrupted downloads, even though local size is different, time trumps size even for -criteria=either
synchronize local -criteria=either -filemask=l_lb_*

One possible fix: set the timestamp on the file when the download is complete. Let it default to 'now', and set to server time when done. This way interrupted/killed sync operations would automatically restart on 2nd attempt. I think this only makes sense for local/remote, not for 'both' where newest file wins.

P.S. It's possible to force size sync by running two sync commands, but it is awkward when file mask is complex.
Example:

# this is only here to force re-download if previous download was killed
synchronize local -criteria=size -filemask=l_lb_*;l_lc_*;l_lp_*;l_mw_*;l_pg_*
# do normal sync - by timestamp
synchronize local -criteria=time -filemask=l_lb_*;l_lc_*;l_lp_*;l_mw_*;l_pg_*