What OS and File System are we talking about here? So far file meta data such as ACLs are not supported on Windows so this could be related to `nix type of OS. Anything special about those files?
is your issue that you are getting the āMetadata was reported as not changed, but still requires being addedā errors, that the backups on 2.0.3.7 are slow, or both?
Just as test (certainly not a solution) does adding --skip-metadata=true improve things at all?
--skip-metadata
Use this option to disable the storage of metadata, such as file timestamps. Disabling metadata storage will speed up the backup and restore operations, but does not affect file size much.
Default value: āfalseā
The Github post mentioned above suggests maybe the issue is related to the multi-threaded processing added in 2.0.3.6. Does setting any of the following to 0 improve things?
Thanks for doing those tests. It sounds like the bug was introduced with the multi-threading code in 2.0.3.6 but isnāt actually caused BY the multi-threading.
If reverting to 2.0.3.5 is an option for you give that a try.
Oh, and it looks like Iām not seeing any answers to @samwās request for OS and filesystem info, can you provide that? Since I canāt replicate the problem on my Windows 10 / NTFS machine Iām assuming thatās not what you are using, but I could be wrong (maybe itās Domain or other permission related).
I have the same issue as ethauvin and Iām on debian:
Linux 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1 (2018-04-29) x86_64 GNU/Linux
/dev/mapper/raid on /media/raid type xfs (rw,relatime,attr2,inode64,sunit=1024,swidth=2048,noquota)
A commonality between us is the use of --check-filetime-only=true
Iāll try to give that a test, but I was under the impression that parameter was added as an attempt to STOP the metadata errors, is that not correct?
Yeah - and thereās no need to test now because one of my backups just came up with that warning yesterday! Yay?
So this was with 2.0.3.7 on Windows 10 w/NTFS and Iām not using --check-filetime-only.
In looking at my history it seems this has happened 3 times total, all since May 11 and on two machines (both Windows 10 w/NTFS). Since I update pretty much as soon as I see an update is available Iām going to assume it started with the 2.0.3.6 version that cam out on April 23.
There were plenty of success runs between these warning runs so whatever the issue is is seems to be transient.
@kenkendk, it seems this message has a typo (āUnexpextedMetadataLookupā vs. āUnexpectedMetadataLookupā) is it worth fixing that BEFORE the surrounding issue is resolved or should it be left alone so as not to muddy the error messages?
...
MainOperation: Backup
ParsedResult: Warning
Version: 2.0.3.7 (2.0.3.7_canary_2018-06-17)
EndTime: 6/25/2018 10:06:30 PM (1529982390)
BeginTime: 6/25/2018 8:57:09 PM (1529978229)
Duration: 01:09:21.5726887
Log data:
2018-06-25 21:51:24 -05 - [Warning-Duplicati.Library.Main.Operation.Backup.FileBlockProcessor.FileEntry-UnexpextedMetadataLookup]: Metadata was reported as not changed, but still requires being added?
Hash: di0UFaGBUyBsWxogpGsL3G2GmRk2kxnigX+IxpcupEU=, Length: 137, ID: 51067