Excluded symlinks are still included in backup

Please describe what you are doing to trigger the bug:
I’m backing up a selective subset of “C:/Users”

Please describe what you expect to happen (but doesn’t):
I expect “C:/Users/All Users” to not be backed up.

Please describe what actually happens (the wrong behaviour):
“C:/Users/All Users” is included in the backup revision.

I’m not familiar with how Duplicacy handles symlinks, but It seems like there’s a bug.

“C:/Users/All Users” is not a real directory, It is a symlink to “C:/ProgramData”. This is outside the backup directory. This also applies to “Default User”, and the only reason why this didn’t cause a backup was insufficient access rights.

SOLUTION (as seen in the screenshot):

Symlinks show up as directories on the left, and clicking “exclude” creates a directory exclude pattern “-All Users/”. The problem is that these particular symlinks are handled as FILES. the correct way to exclude them is “-All Users”

  1. Duplicacy should correctly display and differentiate symlinks from files and folders in the include/exclude browser. (including support for both hard and soft links)
  2. Duplicacy should be consistent. If something is going to be shown as a directory, then it should be excluded with directory syntax.
  3. Duplicacy should create correct include and exclude patterns for symlinks
  4. Duplicacy should provide some configuration for handling symlinks.
    • backup as symlink rather than following it
    • backup symlinks as directory
    • ignore symlinks which link outside backup root
    • ignore symlinks entirely
1 Like

+1 on configurable options surrounding symlink processing

I think it is ok to exclude C:/Users/All Users with -All Users, because a symlink is a file in essence. The issue here is that the web GUI doesn’t know C:/Users/All Users is a symlink and therefore adds the wrong exclude pattern. I’ll fix this in the 1.1.0 release (should be available some time this week).

That’s fine, something consistent is the least i’m looking for here :slight_smile:

Uh, now that you mention it, i have been bitten by this as well, especially on CLI.

Is there a way to make a difference between file symlinks and folder symlinks?
I would expect that folder symlinks can always be excluded by using the / at the end of the folder name (eg. a/long/path/to/a/folder_symlink-or-maybe-a-folder/ <- doesn’t matter if it’s a folder or a symlink to a folder: since i added / i expect that a folder (or symlink target = folder) is exluded if it matches the name).


Hmmmmm… :thinking:



1 Like

Thank you @Christoph for being the good staff member (who knows how to use search) that i am not :slight_smile: :hugs:

Oops, but apparently I’m not capable of replying to the right post. Whatever. This was not so much meant as a comment to you but a more general reminder of related issues. (Though I don’t know exactly how they are technicslly related)

(FYI) I made a formal feature request around symlink handling - Expanded Symlink Support

I’d love to see it get some traction since (selfishly) it would fix a roadblock I’ve hit, but also I’m seeing a lot of confusion and others hoping for more options/features and clear documentation around symlink handling.

Also, for the sake of my specific situation and addressing arguments made against such a feature, I cannot simply filter out (or in) the wanted data. Picture a situation where folders and files are soft and hard linking to each other all over the place in order to construct a super clean and user-navigatable folder structure. It is that folder structure and its contents I want to backup and restore via :d:, not the 1000’s of files buried in 1000’s of subfolders used to construct said folder.

I also find it super misleading that you can navigate through symlink’d folders as if they are “normal” folders in the include/exclude dialog box, you can select them to be included, etc., yet (secretly) :d: will treat these completely differently.

1 Like