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
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