Bug in symbolic link handling?

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.

Is there a way to report this bug?

Thanks for bringing this up!

I’ve flagged this topic as bug related, but for best results you could post it over on GitHub.

Whether you do it here or there, be sure to include the OS(es) you’ve seen this on.

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.

I have added that to the code:

1 Like

So this would fix Symlink restoration incorrectly writes owner and mode through the link · Issue #3127 · duplicati/duplicati · GitHub as well?

Yep, this will fix issue 3127 I belive.

1 Like

@sylerner, I believe this has been implemented in the canary update. If you happen to be updating to that version, please let us know if it resolves the issue for you.

Is the canary release channel stable enough to use for important backups?

Given the amount of time that seems to pass between Beta releases (and there not being many Experimental releases?), it seems the way to if if safe.

As always, thanks!

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.

I appreciate the need to stabilize things after such a big change, and that it can (and probably will) take a while.

Any guess when the next experimental build might be coming out?

Definitely very impressed with duplicati - I’ll be starting larger scale testing in a few weeks when I get back from vacation.