Restore permissions on unix does not handle dangling symlinks

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

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.

I just saw that bugs should be filed on github. More detail over there: Symlink restoration incorrectly writes owner and mode through the link · Issue #3127 · duplicati/duplicati · GitHub

Thanks for digging into this and logging it on GitHub!