Excluded symlinks are still included in backup

Bug
,
#1

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.

image
image.jpg1086×779 126 KB

“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
Expanded Symlink Support
Proposal: following symlinks by pattern
Proposal: following symlinks by pattern
#2

+1 on configurable options surrounding symlink processing

#3

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).

#4

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

#5

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).

2 Likes
#6

Hmmmmm… :thinking:

Oh:

And:

1 Like
#7

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

#8

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)

#9

(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