Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hardlinked symlinks are not supported #2379

Open
ThomasWaldmann opened this issue Apr 2, 2017 · 8 comments
Open

hardlinked symlinks are not supported #2379

ThomasWaldmann opened this issue Apr 2, 2017 · 8 comments

Comments

@ThomasWaldmann
Copy link
Member

@ThomasWaldmann ThomasWaldmann commented Apr 2, 2017

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).
@ThomasWaldmann ThomasWaldmann added this to the 1.1.0b5 milestone Apr 2, 2017
@enkore
Copy link
Contributor

@enkore enkore commented Apr 2, 2017

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

Loading

@ThomasWaldmann ThomasWaldmann removed this from the 1.1.0b5 milestone Apr 3, 2017
@nilsmeyer
Copy link

@nilsmeyer nilsmeyer commented Jun 18, 2018

EDIT: Misunderstood the meaning of "hardlinked symlinks", which is supposed to be a hard link to a symbolic link. I didn't even know this was possible.

Loading

@BarbzYHOOL
Copy link

@BarbzYHOOL BarbzYHOOL commented Jul 17, 2018

"This is a minor issue, likely nobody uses hardlinked symlinks anyway."

I do use them

EDIT: or not

Loading

@BarbzYHOOL
Copy link

@BarbzYHOOL BarbzYHOOL commented Aug 3, 2018

so when saving hardlinks with borg, they are instead soft symlinks? do I understand right?

Loading

@ThomasWaldmann
Copy link
Member Author

@ThomasWaldmann ThomasWaldmann commented Aug 3, 2018

@BarbzYHOOL read the issue title again.

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

The only problem are "hardlinked symlinks".

Loading

@BarbzYHOOL
Copy link

@BarbzYHOOL BarbzYHOOL commented Aug 3, 2018

Lol, my bad! hardlinked symlinks, I thought it meant "hardlinks". Also seems like nilsmeyer didn't get it either "It's just called a hard link (as opposed to a symbolic link, a link is either hard or symbolic)."

Now I understand better why you said "almost nobody use them anyway" (but to be fair, most people also say "do'nt use hardlinks ever, use symlinks" so that's why I confused)

What the hell is a hardlinked symlink? a hardlink on a symlink?

Loading

@ThomasWaldmann
Copy link
Member Author

@ThomasWaldmann ThomasWaldmann commented Aug 3, 2018

yes.

Loading

@yash-fn
Copy link

@yash-fn yash-fn commented Oct 6, 2021

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 innodes seems 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.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants