Metadata was reported as not changed, but still requires being added?


That might explain why you get it on every file…I don’t use filetime-only and I used to get it occasionally, but the last few days it seems to happen every run - but only once.

I’ll try to update once logging catches it.


@Chipmaster nailed it. :+1:

For kicks, I removed check-filetime-only from all of my backups, and every single one of them is working just fine now.

I am getting a lot of 503 errors on HubiC, but I am assuming that it is on their end. I’ll give it a few days before I start hollering. :grin:

@Chipmaster, FYI, my backups are faster now than there were before the metadata issues. Something that used to take 30 minutes, takes 8 now on Windows, although I have not seen much improvements on Linux.


Thanks for letting us know that improved things for you.

Guess we’ll have to review the --check-filetime-only code to figure out where things went wrong. :blush:


It might not be the only problem. I started a new backup on pCloud using WebDav, and on the second run the metadata errors happened for all files in the backup.

I’m also getting some error about not being able to load the Microsoft Azure dll, which seems to correlate with the backup pausing (no activity) for at least 30 minutes. Not sure if that’s related or not though.

Jul 16, 2018 2:31 AM: Failed to load assembly C:\ProgramData\Duplicati\updates\\Microsoft.WindowsAzure.Storage.dll, error message: Could not load file or assembly 'Microsoft.Data.Services.Client, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have other backups starting on pCloud, we’ll see soon enough if the same is happening or not.


I’ve also seen performance improvements by disabling check-filetime-only . On the order of 13hrs -> between 30min and 1hr.