Changing destination path names while retaining incrementals

[rostala]

I ran in to an issue with my Outlook PST profile after changing the destination directory names through the Google Drive website, (and also the profile's name in Syncovery.) After the path change, I was presented with the dialog below. I chose the first option, since that sounded like what I was after. However, I subsequently re-opened the profile, made another change to the destination path, closed it, but was not presented with the dialog a 2nd time. I then did a background run to find out if Syncovery would add a block-level incremental to the existing full backup (per the profile's configuration), but instead, it created a new full backup. What should I have done to get Syncovery to use the existing full backup?

db_mismatch.jpg (84.26 KiB) Viewed 2920 times

Side note: As I write this, per the status below, Syncovery seems to say that it's uploading the backup, but there's nothing showing on Google Drive yet. I guess GD just doesn't show uploads while they're in transit. (Like you would see with other types of data transfer.)

copy_progress.jpg (28.21 KiB) Viewed 2920 times

[tobias]

Hello,
unfortunately this is a real challenge for Syncovery. I don't know if it's supported at all. I will check what can be done.

Yes Google Drive will only show the file when it's completely uploaded. It looks like it will be a complete file.

You can still keep the older files in case you ever want to download an older version of the Outlook.pst file. If you are sure you will never need an older version, then you can delete the older files, but before doing that, I recommend double-checking that the new upload is really a complete standalone copy of the file.

Complete initial uploads have these letters in the filename: .n0.k6.

This means it's number 0 in a series of incrementals, and k6 means it's a complete file (incremental kind 6 = initial upload).

[rostala]

These are the 3 files I have now. The old and new full backups are very close to the same size, and only a day apart, so it seems fair to assume that Syncovery really did make a new full backup. Therefore, I'm just going to delete the 2 older files.

• Outlook.d20220730-u033210.pst.i962706283.n0.k6.s4204700672
• Outlook.d20220730-u073358.pst.i962706283.n1.o0.k0.s4204700672
• Outlook.d20220730-u161328.pst.i970218836.n0.k6.s4204700672

Somehow I failed to tell Syncovery that there was just a change in path, and that everything else was the same. I guess I expected it would look at the checksums or something and prompt to ask if I wanted to continue incrementals from the existing backup. In fairness though, how much need is there for something like that. Because a change in the core path doesn't come up very often. And when it does, why not just take the opportunity to clean house and make new fresh backups. Unless I suppose where versioning is concerned, and the user needs to retain their accumulated versions.

I have a few questions then:

1. When it detected that the paths didn't match, prompted me about it, and I chose to ignore the mismatch, what was supposed to happen?
2. Did a bug prevent it from asking me a 2nd time? (In case it matters: The first time, I changed the subdirectory - in this case, from "ext://Google Drive/[BACKUP]/DIR1" to "ext://Google Drive/[BACKUP]/BU001" - but the 2nd time, I changed the root directory, from "[BACKUP]" to "[BACKUPS]". And that's when it failed to prompt me about the mismatch.)
3. If the extra path detection isn't there, would it be a lot of work to add it? Or is it not worth it because the situation isn't common enough?