hardlinked symlinks are not supported

[ThomasWaldmann]

borg supports hardlinks and it supports symlinks and both are backupped as it should be.

A problem are "hardlinked symlinks".

# on macOS 12
% touch target
% ln -s target symlink1
% ln -P symlink1 symlink2
% ls -li             
40490316 lrwxr-xr-x  2 tw  staff  6 May 11 12:32 symlink1 -> target
40490316 lrwxr-xr-x  2 tw  staff  6 May 11 12:32 symlink2 -> target
40490309 -rw-r--r--  1 tw  staff  0 May 11 12:31 target

This part of #2324 is not addressed yet (except that symlinks are not in the documented list of supported hardlinked fs objects).

The problem here is the dual-use of item.source (see #2343), which should be solved first.

Then, hardlinked symlinks could be supported in same way as other hardlinked fs objects.

Note:

• This is a minor issue, likely nobody uses hardlinked symlinks anyway.
• If somebody uses them, the only negative effect is that such hardlinks are not archived as hardlinks (and thus: not restored as hardlinks).

[enkore]

• Since permissions on symlinks are ignored and symlinks cannot be changed after creation, the usual benefits of hardlinks don't apply. The only observable effect is st_nlink (and one less inode used).

[yash-fn]

so given its a hardlink to a symlink, the only tangible benefit would be that when one of the symlinks is overwritten to point elsewhere the other one would similarly be updated to point to the new location as well, as normal hard links work. But I tested this on my system using ln -sf (which as far as I'm aware is the only way to change a symlink without deleting first) and it appears that ln will first delete then write breaking any hardlink on the symlink anyways. Thus, if by itself this functionality is not present, perhaps this issue can be safely ignored altogether since separate inodes see to function the exact same as hardlinking them. Right? And disk size is irrelevant when talking about links.

In other words, unless I am mistaken and please correct me if I am, there is no way to 'edit' a symlink other than to delete it first then create a new one with a new innode. Borg would only make sense include this feature if there is a way to change the symlink while preserving the innode and there appears to none.

I do not know, however, if this applied to mknod/devices however. But it appears symlinks are pretty safe to ignore.

[ThomasWaldmann]

Working on this in #6663.

Since that uses item.hlid to relate hardlinks, there is no issue with usage of item.source any more.

[ThomasWaldmann]

borg2 branch supports hardlinked symlinks.

[prahal]

Is this fixed in borg 1.2? Maybe the FAQ should be updated to stop advertising hardlinked symlinks are not supported?

For hardlinked symlinks, the hardlinking can not be archived (and thus, the hardlinking will not be done at extraction time). The symlinks will be archived and extracted as non-hardlinked symlinks, see #2379.

EDIT: sorry I finally found that borg2 is indeed borg v2 the current master branch in beta. This FAQ section thus still holds.

[ThomasWaldmann]

This is rather a design limitation of the borg item metadata (in borg < 2) than a bug. It's fixed in master branch, which will be released as borg 2 at some time in the future.