When restoring backups, duplicati attempts to set the timestamp of symbolic links.
This causes two problems.
First, this changes the timestamp of the target of the symlink, not the symlink itself. This is always wrong, since the timestamp of the symlink is not generally the same as the target. Also, the target can be outside of the backup set and has been updated, so setting its timestamp is setting it into the past.
Additionally, if the target of the symbolic link doesn’t exist, this causes deplicati to generate an error, since it is unintentionally trying to set the timestamp of a non-existent target file.
BTW, a similar problem in the handling of symlinks happens when trying to set owner or permissions. If the target exists, its metadata is changed, not that of the symlink. And if the target is missing, an error is thrown.
The fix for this should be very simple: don’t attempt to set any metadata on symbolic links.
@sylerner, I believe this has been implemented in the 2.0.3.7 canary update. If you happen to be updating to that version, please let us know if it resolves the issue for you.
No. We do run unittests on each commit, but things slip through.
The idea with the canary is that users are aware that they get the new stuff first, but know that it might break things. The beta releases are for people who prioritize not having to deal with broken stuff (at least until we release a real stable version…). Experimental hits somewhere between the two, and has so far been used as a staging release prior to a beta.
Ideally, we would release more experimental and beta releases, but right now I need to deal with the fallout from the concurrent processing changes as well as some newly introduced issues.