Instead of checking for the Admin User it would be more general to check whether the user has the SeCreateSymbolicLinkPrivilege privilege.

Additional there is the possibility to create symlinks without elevation if developer mode is activated for Windows 10 and CreateSymbolicLink is called with the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag.

@hgraeber Implemented in my last commit. Please have a look.

In principle the check for the check for the privilege looks good to me, but I am a go newbie coming from C/C++.

After thinking more about this, I have doubts whether it is worth making this check to this extent.The only thing it does is getting an error message before creating symlinks. Simply trying to create a symlink an having a error message if it fails should be sufficient. Having the privilege - eg. through an elevated command prompt - is needed in both cases.

So dropping

// Windows does not allow non-admins to create soft links.
if runtime.GOOS == "windows" {
    return nil
}

in createSymlinkAt may be enough to solve the issue.

@hgraeber A valid option. I'd add some windows specific code to the error handling to give the user a more specific source of the problem inside the error handling block after calling fs.Symlink(). I'm going to wait for some official feedback on how to continue before putting more work into this PR.

Please, implement this. It's been 2 years

Please, implement this. It's been 2 years

It's pretty clear restic is just unsupported/abandonware on Windows. It's had data loss inducing bugs with both backup and restore containing symlinks/junctions being broken since release, and unmerged fixes sitting for years.

It's pretty clear restic is just unsupported/abandonware on Windows. It's had data loss inducing bugs with both backup and restore containing symlinks/junctions being broken since release, and unmerged fixes sitting for years.

Windows support for restic has always been primarily community driven, AFAIK there's not much/no windows usage among the maintainers. Nevertheless, I try to also fix Windows-specific problems from time to time. But some pull requests get buried under the large pile of other PRs and then it takes quite some time to dig them out again.

Would you care to elaborate which specific bugs you are referring to?

I will look into this in a few days.

@MichaelEischer What about os.Symlink()? Will this be fixed or should this PR keep the workaround for now?

Will this be fixed or should this PR keep the workaround for now?

Please change fs.Symlink() in internal/fs/file.go to

return os.Symlink(oldname, fixpath(newname))

and remove the workaround afterwards.

@fgma Any progress with cleaning up the PR?

@MichaelEischer Looking into it right now.

I've rebased and squashed the PR to remove the duplicate commits. The changelog now also contains links to all fixed issues and this PR.