Re: WinSCP 5.1.2 does not resume sync when interrupted.
You rock. Thank you for your detailed explanation. :)
- navilor
Post a reply
Topic review
- martin
Re: WinSCP 5.1.2 does not resume sync when interrupted.
Thanks for your detailed report. Though, the fact is, that WinSCP does not (and never did) support resuming synchronization the way you describe.
You may had have that impression in case your previous server returned directory listing in fixed order (i.e. alphabetically sorted). Then, although WinSCP always starts sync from a scratch, the first not-synced file it encounters, would likely be the file, where the previous sync was interrupted. While if your new server returns directory listing in (seemingly) random order, the first not-synced file may be completely different one.
You may had have that impression in case your previous server returned directory listing in fixed order (i.e. alphabetically sorted). Then, although WinSCP always starts sync from a scratch, the first not-synced file it encounters, would likely be the file, where the previous sync was interrupted. While if your new server returns directory listing in (seemingly) random order, the first not-synced file may be completely different one.
- navilor
WinSCP 5.1.2 does not resume sync when interrupted.
I have a problem that I hope is a PEBKAC error on my end. Per your recommendations at the link below I am providing everything that I can.
https://winscp.net/eng/docs/reporting
High level overview:
I am running WinSCP using a script against my new and clean server. When I interrupt either an FTP or SFTP session WinSCP does not traverse into the proper subdirectory when I resume. WinSCP instead goes to the root directory and "continues" from there.
Details below:
1) Version of WinSCP you are using (you should be using the latest version if possible).
WinSCP version 5.1.2 (Build 2816)
2) If the problem started to occur after upgrade, mention the last version of WinSCP which was working for you.
No. This issue appears to have started when I moved from Freenas 7 to Freenas 8.3.1. I have ensured that my server is using UTC in the BIOS. I have consulted the following page before submitting my question:
https://winscp.net/eng/docs/timestamp
The timestamps reported on the server appear to match the timestamps on my PC.
The hardware for my server has not been modified. I deleted the entire RAIDZ1 array (four 1TB drives for 3TB usable) and rebuilt it just to be safe. Permissions are set back to normal but that does not mean that this isn't a permissions issue as files will be deleted on the server if they are deleted on the client.
Due to the nature of my script, and this may be part of the problem, I needed to create a subdirectory structure on the server. This means that the directories that I manually created have different timestamps on the server than they do on Win7 64bit Pro. This does not entirely make sense as the directories that WinSCP creates on the remote server are skipped when an update is resumed.
3) Version of Microsoft Windows you are running WinSCP on.
Windows 7 Professional SP1 64bit
4) Transfer protocol (SFTP, FTP or SCP). For SFTP include also the protocol version (if you ever succeeded to login). You can see it in Server/protocol information dialog as "SFTP-X".
This issue happens with both SFTP and FTP.
5) Mention if you use GUI or scripting/automation. If you use GUI, specify interface style you are using (Commander or Explorer).
This is most likely either a scripting issue or a server configuration issue on my end.
6) If you experience an error, include full error message. You may use Ctrl+C to copy the message, then paste it (Ctrl+V) to the post. Also check list of common error messages.
No errors are returned.
7) Try to describe precise steps that lead to the problem (where do you click, what keys do you press, what do you see, etc.). If you are not able to reproduce the problem with the steps, it is probably not worth to report it as I will not be able to reproduce it (and solve) too.
I have a very large script to sync my PC with my server. Below is a portion that I use when I want to sync one drive instead of my entire box.
This issue also happens if I use ftp:
Previously when I ran this script with FreeNAS 7 I could interrupt the script and upon running it again it would resume updating in the subdirectory where it left off. With FreeNAS 8.3.1 this is no longer the case.
8) Software of the server you are connecting too (if you can get this information).
FreeNAS 8.3.1
9) For scripting/automation-related issues, include your full script, command-line you use to run WinSCP, and output you see on WinSCP console.
The script is shown above. The output is below:
As shown above the sync did not resume in the "OtherVideo" directory but instead ignored that directory and reverted back to the root directory of the script.
10) If your problems relates to interaction with remote server, please post a full log file showing the problem.
The server reports no errors.
My guess is that this is a massive PEBKAC error.
https://winscp.net/eng/docs/reporting
High level overview:
I am running WinSCP using a script against my new and clean server. When I interrupt either an FTP or SFTP session WinSCP does not traverse into the proper subdirectory when I resume. WinSCP instead goes to the root directory and "continues" from there.
Details below:
1) Version of WinSCP you are using (you should be using the latest version if possible).
WinSCP version 5.1.2 (Build 2816)
2) If the problem started to occur after upgrade, mention the last version of WinSCP which was working for you.
No. This issue appears to have started when I moved from Freenas 7 to Freenas 8.3.1. I have ensured that my server is using UTC in the BIOS. I have consulted the following page before submitting my question:
https://winscp.net/eng/docs/timestamp
The timestamps reported on the server appear to match the timestamps on my PC.
The hardware for my server has not been modified. I deleted the entire RAIDZ1 array (four 1TB drives for 3TB usable) and rebuilt it just to be safe. Permissions are set back to normal but that does not mean that this isn't a permissions issue as files will be deleted on the server if they are deleted on the client.
Due to the nature of my script, and this may be part of the problem, I needed to create a subdirectory structure on the server. This means that the directories that I manually created have different timestamps on the server than they do on Win7 64bit Pro. This does not entirely make sense as the directories that WinSCP creates on the remote server are skipped when an update is resumed.
3) Version of Microsoft Windows you are running WinSCP on.
Windows 7 Professional SP1 64bit
4) Transfer protocol (SFTP, FTP or SCP). For SFTP include also the protocol version (if you ever succeeded to login). You can see it in Server/protocol information dialog as "SFTP-X".
This issue happens with both SFTP and FTP.
5) Mention if you use GUI or scripting/automation. If you use GUI, specify interface style you are using (Commander or Explorer).
This is most likely either a scripting issue or a server configuration issue on my end.
6) If you experience an error, include full error message. You may use Ctrl+C to copy the message, then paste it (Ctrl+V) to the post. Also check list of common error messages.
No errors are returned.
7) Try to describe precise steps that lead to the problem (where do you click, what keys do you press, what do you see, etc.). If you are not able to reproduce the problem with the steps, it is probably not worth to report it as I will not be able to reproduce it (and solve) too.
I have a very large script to sync my PC with my server. Below is a portion that I use when I want to sync one drive instead of my entire box.
option batch continue
option transfer binary
option confirm off
open sftp://username:password@192.168.1.4
lcd M:
cd /mnt/share/kevin/misc
synchronize remote -delete -mirror -nopreservetime -filemask=|"M:\$Recycle.Bin\; M:\System Volume Information\; *.tmp; *.~;"
This issue also happens if I use ftp:
open ftp://username:password@192.168.1.4
Previously when I ran this script with FreeNAS 7 I could interrupt the script and upon running it again it would resume updating in the subdirectory where it left off. With FreeNAS 8.3.1 this is no longer the case.
8) Software of the server you are connecting too (if you can get this information).
FreeNAS 8.3.1
9) For scripting/automation-related issues, include your full script, command-line you use to run WinSCP, and output you see on WinSCP console.
The script is shown above. The output is below:
winscp> open sftp://kevin:kevin31415926@192.168.1.4
Searching for host...
Connecting to host...
Authenticating...
Using username "kevin".
Authenticating with pre-entered password.
Authenticated.
Starting the session...
Reading remote directory...
Session started.
Active session: [1] kevin@192.168.1.4
winscp> option batch continue
batch continue
winscp> option transfer binary
transfer binary
winscp> option confirm off
confirm off
winscp> lcd M:
M:\
winscp> cd /mnt/share/kevin/misc
/mnt/share/kevin/misc
winscp> synchronize remote -delete -mirror -nopreservetime M: /mnt/share/kevin/misc -filemask=|"M:\$Recycle.Bin\; M:\System Volume Information\; *.tmp; *.~;"
Comparing...
Local 'M:' => Remote '/mnt/share/kevin/misc'
Synchronizing...
Local 'M:' => Remote '/mnt/share/kevin/misc'
M:\Acronis Bare System | 0 KiB | 0.0 KiB/s | binary | 0%
M:\Acronis Clean System | 0 KiB | 0.0 KiB/s | binary | 0%
M:\Acronis New System | 0 KiB | 0.0 KiB/s | binary | 0%
M:\AutorunsPortable | 0 KiB | 0.0 KiB/s | binary | 0%
M:\AutorunsPortable\App | 0 KiB | 0.0 KiB/s | binary | 0%
M:\...\App\AppInfo | 0 KiB | 0.0 KiB/s | binary | 0%
M:\...\appicon.ico | 21 KiB | 1122.4 KiB/s | binary | 100%
M:\...\appicon_128.png | 3 KiB | 1312.4 KiB/s | binary | 100%
M:\...\appicon_16.png | 0 KiB | 1345.8 KiB/s | binary | 100%
M:\...\appicon_32.png | 1 KiB | 728.1 KiB/s | binary | 100%
M:\...\appinfo.ini | 1 KiB | 760.9 KiB/s | binary | 100%
M:\...\AppInfo\EULA.txt | 6 KiB | 984.0 KiB/s | binary | 100%
M:\...\installer.ini | 0 KiB | 994.3 KiB/s | binary | 100%
M:\...\AppInfo\Launcher | 0 KiB | 655.8 KiB/s | binary | 0%
M:AutorunsPortable.ini | 0 KiB | 663.1 KiB/s | binary | 100%
M:\...\App\Autoruns | 0 KiB | 663.1 KiB/s | binary | 0%
M:\...\autoruns.chm | 48 KiB | 1262.3 KiB/s | binary | 100%
M:\...\autoruns.exe | 642 KiB | 4196.0 KiB/s | binary | 100%
M:\...\autorunsc.exe | 562 KiB | 4570.8 KiB/s | binary | 100%
M:\...\Autoruns\Eula.txt | 6 KiB | 4595.2 KiB/s | binary | 100%
M:\...\App\DefaultData | 0 KiB | 4595.2 KiB/s | binary | 0%
M:\...\settings | 0 KiB | 4595.2 KiB/s | binary | 0%
M:\...\Autoruns.reg | 0 KiB | 4348.4 KiB/s | binary | 100%
M:\...\App\readme.txt | 0 KiB | 4349.0 KiB/s | binary | 100%
M:AutorunsPortable.exe | 152 KiB | 4402.0 KiB/s | binary | 100%
M:\AutorunsPortable\Data | 0 KiB | 4402.0 KiB/s | binary | 0%
PortableApps.comInstaller | 0 KiB | 4402.0 KiB/s | binary | 0%
M:\...\license.ini | 0 KiB | 4402.1 KiB/s | binary | 100%
M:\...\Data\settings | 0 KiB | 4402.1 KiB/s | binary | 0%
M:\...\Autoruns.reg | 1 KiB | 4214.9 KiB/s | binary | 100%
AutorunsPortableSettings. | 0 KiB | 4215.3 KiB/s | binary | 100%
M:\...\Data\Temp | 0 KiB | 4215.3 KiB/s | binary | 0%
M:\...\help.html | 4 KiB | 4227.6 KiB/s | binary | 100%
M:\AutorunsPortable\Other | 0 KiB | 4227.6 KiB/s | binary | 0%
M:\...\Other\Help | 0 KiB | 4227.6 KiB/s | binary | 0%
M:\...\Other\Help\images | 0 KiB | 4227.6 KiB/s | binary | 0%
M:...\donation_button.png | 1 KiB | 4044.0 KiB/s | binary | 100%
M:\...\images\favicon.ico | 1 KiB | 4047.1 KiB/s | binary | 100%
help_background_footer.pn | 0 KiB | 4047.5 KiB/s | binary | 100%
help_background_header.pn | 0 KiB | 4048.3 KiB/s | binary | 100%
M:\...\help_logo_top.png | 2 KiB | 4055.3 KiB/s | binary | 100%
M:\...\Other\Source | 0 KiB | 4055.3 KiB/s | binary | 0%
M:...\AppNamePortable.ini | 0 KiB | 4056.0 KiB/s | binary | 100%
M:...\LauncherLicense.txt | 17 KiB | 3930.9 KiB/s | binary | 100%
M:\...\Source\Readme.txt | 2 KiB | 3936.6 KiB/s | binary | 100%
AutorunsPortable_11.5_Eng | 754 KiB | 4470.2 KiB/s | binary | 100%
M:\BIOSmame133u4.7z | 19931 KiB | 5615.0 KiB/s | binary | 100%
M:\CygwinInstallFiles | 0 KiB | 5592.3 KiB/s | binary | 0%
M:\CygwinInstallFiles.7z | 122148 KiB | 5755.1 KiB/s | binary | 100%
M:\ffmpeg.7z | 19821 KiB | 5737.7 KiB/s | binary | 100%
M:\OtherVideo | 0 KiB | 5737.7 KiB/s | binary | 0%
M:\...\Art Laffer.mp4 | 13108 KiB | 5750.9 KiB/s | binary | 6%
Terminated by user.
winscp> synchronize remote -delete -mirror -nopreservetime M: /mnt/share/kevin/misc -filemask=|"M:\$Recycle.Bin\; M:\System Volume Information\; *.tmp; *.~;"
Comparing...
Local 'M:\AutorunsPortable\Data\PortableApps.comInstaller' => Remote '/mnt/share/kevin/misc/AutorunsPortable/Data/PortableApps.comInstaller'
Synchronizing...
Local 'M:' => Remote '/mnt/share/kevin/misc'
M:\sheen.mp4 | 14914 KiB | 5759.3 KiB/s | binary | 4%
Terminated by user.
winscp>
As shown above the sync did not resume in the "OtherVideo" directory but instead ignored that directory and reverted back to the root directory of the script.
10) If your problems relates to interaction with remote server, please post a full log file showing the problem.
The server reports no errors.
My guess is that this is a massive PEBKAC error.