Canonical path: resolve symbolic links?

tobast commented 2 months ago

Have you checked borgbackup docs, FAQ, and open GitHub issues?

Yes

Is this a BUG / ISSUE report or a QUESTION?

Issue

System information. For client/server mode post info for both machines.

Your borg version (borg -V).

Git repository master branch, 1.2.4 and probably all recent-ish versions

Operating system (distribution) and version.

Any

Hardware / network configuration, and filesystems used.

/

How much data is handled by borg?

/

Full borg commandline that lead to the problem (leave away excludes and passwords)

borg -r /tmp/foo/ rlist

Describe the problem you're observing.

Borg has a built-in protection against repository relocation, which can be disabled with the BORG_RELOCATED_REPO_ACCESS_IS_OK environment variable. This check, however, serves security purposes; if possible, it is better not to disable it.

On backup servers, I often find myself creating repositories in some non-root volume, mounted at eg. /mnt/borg. For convenience, I often create a symlink ~borg/repos --> /mnt/borg.

This, however, breaks this check: repositories paths are not normalized by resolving symlinks, and if I eg. have a borg prune running automatically on the ~borg/repos/... paths, but run once manually any command on /mnt/borg/..., the next automatic run of prune will break.

Would it be possible to resolve symlinks, eg. in the canonical_path function, in order to fix this behaviour?

Can you reproduce the problem? If so, describe how. If not, describe troubleshooting steps you took before opening the issue.

borg -r /tmp/foo rcreate -e none  # or whatever, this repository won't be really used
ln -s /tmp/foo /tmp/bar
borg -r /tmp/foo rlist  # works fine
borg -r /tmp/bar rlist  # complains with directory relocation
borg -r /tmp/foo rlist  # complains again with directory relocation

ThomasWaldmann commented 2 months ago

Yeah, I see that issue in that situation. Of course, one solution is "don't do that, be consistent".

IIRC, that canonical path might also be used for display purposes and in that case it might be confusing if you have one path on the borg commandline and a different path in borg's output (because it resolved some symlink).

tobast commented 2 months ago

Not doing that is of course a solution :)

If I try to see a way of allowing this without breaking anything, would it be possible to

store as the cached/displayed path exactly as it is done currently (eg. at first access)
yet accept the paths as equivalent when checking for relocation (eg. by using Path.resolve on both sides of the equality test)?

If this, or something else, seems relevant to you, I could contribute a MR.

borgbackup / borg