Interrupted initial backup not resuming

I read through this thread: Resuming interrupted backup takes hours (incomplete snapshots should be saved)

But it’s a little old, it’s basically on windows and it doesn’t cover what I think I’m seeing…

CLI Linux x64 v2.7.2…
Large initial backup to a Google Drive (storage where I already have a number of other repositories successfully). At some point Google throws a 400 and duplicacy aborts, not entirely sure why, but maybe due to how long the backup is running. The Incomplete file/status is apparently saved, because attempting to resume DOES find that info. However, after a long time of “Listing all chunks”, I get a “Skipped 0 files from previous incomplete backup”?

That doesn’t make sense. How is it possibly attempting to resume if it can not skip the files it previously uploaded???

This can happen if the first to upload is a large file and it had not been completely uploaded when the backup was aborted. You can open .duplicacy/incomplete to see its content. It is just a json file.

No, according to the output from the backup command, it has uploaded maybe 100 files.

The incomplete file appears to list chunks that have been uploaded (assumption), but it doesn’t list what files in the local repository are complete (via the chunks). Is a restart of the backup causing duplicacy to re-scan the filesystem and re-calculate all the chunks for each file to determine whether they are already present in the remote storage? The “Listing all chunks” seems to take a very long time.

EDIT: Interesting. This time I had to restart, though the “Listing all chunks” took a long time (well over an hour), it appears that the backup resumed where it left off. Wonder why that wasn’t the case on my previous restart.