martin wrote:

I'll leave the resuming there for now.
Yes the behavior has changed. Synchronization was completely re-factored in 3.8 beta. As part of that, order of actions has changed. Previously the deletion was done after transfers, not before. However it still must have failed, because the deletion of filepart file was still scheduled. But the file no longer exists once the transfer finishes, so the deletion must have failed.
I'll try to solve it in the next release.

Thanks. I will look forward to your next release.

I'll leave the resuming there for now.
Yes the behavior has changed. Synchronization was completely re-factored in 3.8 beta. As part of that, order of actions has changed. Previously the deletion was done after transfers, not before. However it still must have failed, because the deletion of filepart file was still scheduled. But the file no longer exists once the transfer finishes, so the deletion must have failed.
I'll try to solve it in the next release.

I see your point.

Can you imbed a date and timestamp into the file name in front of the word filepart so that you will know what version the partial file is associated with?

In my case I use WinSCP to securely backup large files across the internet and then cancel the job in the morning so that day time bandwidth is not affected by large transfers. Because of this approach I leave large fileparts on the backup machine knowing that they will be resumed the following evening when batch WinSCP is started again.

BTW was the behavior changed in 3.8.1. I recall this working fine in 3.7 and possibly 3.8 beta

tom1 wrote:

Yes, that is another way of putting it. When I manually restart a batch job that is too continue sync the filepart file (or interrupted transfer) is deleted rather than resumed.

OK, I've found it. "Obsolete" remote files are deleted before upload. And the "filepart" file is considered obsolete, so it is removed (if you have enabled deleting of files). I do not know what is good solution. I'm not even sure if it is good idea to resume file transfer for synchronisation. How do you know that the file part is from the same version of the source file? What do you think?

martin wrote:

tom1 wrote:

When the batch process begins an in progress transfer suffixed with filepart is immediately deleted.

Do you mean that transfer is not resumed?

Yes, that is another way of putting it. When I manually restart a batch job that is too continue sync the filepart file (or interrupted transfer) is deleted rather than resumed.

tom1 wrote:

When the batch process begins an in progress transfer suffixed with filepart is immediately deleted.

Do you mean that transfer is not resumed?

I just upgraded from the 3.8 beta to the 3.8.1 code on XP and noticed that fileparts are being deleted in batch mode but NOT in GUI mode.

I use the following file to sync folders across machine:

open tom@myother.site.com
option synchdelete on
option batch on
option transfer binary
lcd C:\local.sync.folder
cd /home/tom
synchronize remote
close
exit

When the batch process begins an in progress transfer suffixed with filepart is immediately deleted.

Any ideas?