I restored a directory which had an old emacs lock file in it. an emacs lock file is a symlink named .#foo whose target is not a file, but is just a string which looks like user@host.pid:timestamp.
When duplicati restored this, I got an error in the log:
Failed to apply metadata to file: "/tmp/restore-marc/foo/.#bar", message: Could not find file "/tmp/restore-marc/foo/.#bar" => Could not find file "/tmp/restore-marc/foo/.#bar"
The command line tool chown uses the -h flag to handle this, which calls fchownat with AT_SYMLINK_NOFOLLOW to modify the link owner.
Looking at the logs again, it looks like the symlink doesn’t even need to be dangling. I got the same error for a relative symlink to a file which does exist and was restored by the backup. I wonder if the link was restored before the file, leading to a similar error.
One more observation: If the restored symlink points outside of the restore directory, it appears the permissions of the target are changed. This is especially bad. Restoring to a new target directory should not be modifying existing files on disk. In this case it was probably harmless, but it’s easy to imagine cases where modifying permissions or ownership of a non-restored file could be very bad.
Thanks for digging into this and logging it on GitHub!