Checking errors, related to #1400. Unexpected result count: 0, expected 1

Error in my log:

    2019-01-03 00:37:29 -05 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-CheckingErrorsForIssue1400]: Checking errors, related to #1400. Unexpected result count: 0, expected 1, hash: mzp5GXIVXICmXDUaGPQ6T0RBjJd6FUvGhv+6IHUcRV8=, size: 68544, blocksetid: 63134, ix: 47, fullhash: 6xvaiAfAUnq3x1pjPRmcpeCoyKY8L/mMClwsTQRhD8Q=, fullsize: 4881344,
    2019-01-03 00:37:29 -05 - [Error-Duplicati.Library.Main.Database.LocalBackupDatabase-FoundIssue1400Error]: Found block with ID 253058 and hash mzp5GXIVXICmXDUaGPQ6T0RBjJd6FUvGhv+6IHUcRV8= and size 52128
]

These are related to git issue Failed to process path: xxx => Unexpected result count: 0, expected 1 · Issue #1400 · duplicati/duplicati · GitHub. I wasn’t sure if I should post here or there so I posted here.

Some notes. I have the default --snapshot-policy = off which I will turn on for the future. I think default should be on, but that’s just me.

And I know it’s off (well, at least I think so) because I also get these warnings:

    Failed to process path: C:\Users\USER1\NTUSER.DAT,
    Failed to process path: C:\Users\USER1\ntuser.dat.LOG1,
    Failed to process path: C:\Users\USER1\ntuser.dat.LOG2,
    Failed to process path: C:\Users\USER1\AppData\Local\Microsoft\Windows\UsrClass.dat,
    Failed to process path: C:\Users\USER1\AppData\Local\Microsoft\Windows\UsrClass.dat.LOG1,

Interestingly, I did NOT get these errors first time.

I am trying to backup two Windows user trees.

First time, ran as USER1 un-elevated/not-prived and I could not backup USER2 cuz no access.

Second time, ran as USER1 with Run as administrator and I could then backup USER2 but I got the errors and warnings above.

So with no snapshot perhaps this is simply that files changed between start and end of backup.

Indeed, adding the advanced option --snapshot-policy=on to my backup removed my errors and warnings.

I’m not sure how the #1400 error is related to snapshots but if that solved the problem, great!

The reason snapshots aren’t enabled by default is because not everybody runs as a privileged user so they would all get warnings/errors about not being able to take a snapshot.

I’m marking your post as the solution - please let me know if you disagree.

I haven’t heard that anyone knows why this old error is back again, but the best-informed guess might be

and to extend the thought (at my own risk), if a snapshot freezes the file view, that might avoid the error…