Partial file update not working as expected after upgrading

[probspot3]

Hello,

I have been using Syncovery to make a daily backup of a 60GB-large virtual disk of my virtual machine. I've been using Syncovery's "Synthetic Backup" feature which saves only changed blocks and is thus perfectly suited for the task.

After upgrading from 7.15 to 7.46c, the source file is for some reason excluded from the partial updating, and instead of transferring around 200-300MB daily, Syncovery tries to transfer 60GB again.

Relevant output of the log file before the upgrade:


===========================

10.03.2016 11:43:11 Testing K:\Backups\Gentoo x86_64 _kernel_\Gentoo_x86_64.d20160310-u013636.vdi.$$$
Copy L->R C:\Users\myuser\VirtualBox VMs\Gentoo x86_64 _kernel_\Gentoo_x86_64.vdi (60,0GB)
11:43:19.568 Database performance: AddRecord=0.0s, FindRecord=0.0s, AddAlternatesTicks=0.0s, FindParentTicks=0.0s, OpenFolderTicks=0.0s
11:43:19.602 Database closed

Reference database closed: C:\ProgramData\Syncovery\Database\Virtualbox VM Backup.syncfdb (172 Entries)

SUMMARY
------------------------------------------------------------------
Short Results: 3 copied (60,0GB)
Operation completed at 11:43:19 on 10.03.2016
Total duration: 00:13:19

Copied To Right Side: 3 (60,0GB)
Files updated on Right side : 3
Older versions removed : 2

Transfer amount saved due to partial file updating : 59,7GB
Remaining actual transfer amount for eligible files: 271,9MB


===========================


Relevant output of the log file after the upgrade:

===========================

Not using partial file updating for Gentoo_x86_64.vdi (destination file does not seem to exist: Gentoo_x86_64.d20160405-t010258.vdi.s64426606592.zip)
Destination MD5 size is not as expected, is=0, expected=125833216
Zipping operation canceled.
05.04.2016 10:38:10 Error adding to zip: C:\Users\myuser\VirtualBox VMs\Gentoo x86_64 _kernel_\Gentoo_x86_64.vdi
Error creating or writing to ZIP file: K:\Backups\Gentoo x86_64 _kernel_\Gentoo_x86_64.d20160405-u082617.vdi.$$$: Operation Canceled
Operation Canceled
Operation Canceled
Zipping

===========================

In the latter case I interrupted the transfer because it was apparently taking too long.

The destination file created by the first sync run is called "Gentoo_x86_64.d20160404-u230258.vdi.i964544617.n0.k6.s64426606592.zip". I don't understand why with the next run the partial file updating expects to find the file "Gentoo_x86_64.d20160405-t010258.vdi.s64426606592.zip".

I tried to delete the profile database and redo the fresh initial sync with the same results.

My profile settings:

[General]
Name=Virtualbox VM Backup
LastModified=05.04.2016 01:30:06
LeftPath=C:\Users\myuser\VirtualBox VMs\Gentoo x86_64 _kernel_
RightPath=K:\Backups\Gentoo x86_64 _kernel_
LeftToRight=Yes

[Exact Mirror Config]
ExactMirrorDeletes=Yes
ExactMirrorReplacesNewerFiles=Yes

[File Access]
DatabaseSafe=Yes
VolumeShadowMode=vsNone

[Files]
MaxParallelCopiers=1

[Files->More]
AutoResume=Yes

[Job]
RightVolumeMustBe=BACKUP

[Exclusion Masks]
ExcludeFileMasks=\Snapshots\*.sav;\Logs\*

[Safety->Unattended]
UnattendedDeleteMaxPercent=10

[Schedule]
ScheduledNormally=Yes
RepeatAfter=Yes
NextDateTime=06.04.2016 11:31:00
OrigTimeOfDay=11:30:00

[Schedule->More]
RandomDelay=6
WarnIfNotRunForDays=4

[Special]
PartialFileUpdating=Yes

[Special->Database]
NameForDatabase=Virtualbox VM Backup
DBLeftBasePath=C:\Users\myuser\VirtualBox VMs\Gentoo x86_64 _kernel_
DBRightBasePath=K:\Backups\Gentoo x86_64 _kernel_

[Synthetic Backup]
CPStrategy=cpNone
RemoveIncrementalsOlderThanDays=1

[Versioning]
KeepMultipleVersions=Yes
MaxVersions=30
UseVersioningFolder=Yes
VersioningFolder=Syncovery_Older
FilenameEncoding=Yes
VersionTimestampNaming=Yes

[Zipping]
ZipFilesIndividually=Yes
ZipDirectlyToDest=Yes
ZipCompressionLevel=0
DecryptRightToLeft=No

[superflexible]

Hello,
I have made some tests and can't produce the problem here. Because of that, I would need more detailed log files from you. Please go to the Program Settings dialog, tab sheet Logs, and choose "SmartTracking Details" as well as "Synthetic Details".

Then please install version 7.46e.

Please delete the database files in C:\ProgramData\Syncovery\Database and also rename or delete your destination folder so that it can start fresh.

Then run the job twice until you notice the problem.

I would need the complete log files please, you can send them to support@syncovery.com or post them here.

[probspot3]

Extended logs after first and after second run on 7.46c are attached. The second run did not complete successfully because of insufficient storage space as it tried to copy the whole VDI again.

Before doing those runs I deleted all log files for that profile and all database files. I also deleted the destination directory and let Syncovery re-create it.

[superflexible]

Sorry for the delay, I am working on this now.

[superflexible]

The problem occurs when Synthetic Backup is combined with the option "Zip directly to destination". It will be fixed in today's update.

[superflexible]

This issue was fixed in 7.47c yesterday.

[probspot3]

Confirming it was fixed in 7.47c.

Thanks a lot.