Patternfile doesn't seem to work with relative paths

[bobthebadguy]

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

Yes

Is this a BUG / ISSUE report or a QUESTION?

Question

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

Arch linux

Your borg version (borg -V).

1.1.17

Operating system (distribution) and version.

Hardware / network configuration, and filesystems used.

Zfs

How much data is handled by borg?

None

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

borg create --list --dry-run --patterns-from patternfile ~/borgrepo::test

Patternfile:

R /home/user/borgtest
- dir1
+ dir2/includeme
- dir2

Directory structure:

|-- dir1
|   |-- dir1-a
|   `-- dir1-b
|-- dir2
|   |-- excludeme
|   `-- includeme

Describe the problem you're observing.

In the patternfile, after specifying a root with R, exclusion rules still require an absolute path.
With the setup described above, I would expect dir1 not to be backed up, and only includeme to be backed up, and not excludeme.

What actually happens is that everything is backed up:

- /home/user/borgtest/dir1/dir1-b
- /home/user/borgtest/dir1/dir1-a
- /home/user/borgtest/dir1
- /home/user/borgtest/dir2/includeme
- /home/user/borgtest/dir2/excludeme

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

The patternfile only works if all the paths are absolute. This becomes a problem, since some of my paths are very long.

The docs seem to suggest that using R sets a root from which rules apply from, which doesn't seem to be happening.

[ThomasWaldmann]

• DONE (docs improved): check if docs need to be more clear
• TODO check if we can easily implement relative patterns

[bobthebadguy]

After re-reading the docs a few times, I think I understand.

R is just a replacement for specifying paths on the command line and it doesn't allow relative paths:

borg create ~/borgrepo::test ~/backmeup
    This here can be replaced by R ↑

Is that correct? Also, I assume that specifying multiple roots works the same way.

The docs don't seem really clear on that specific part.

[ThomasWaldmann]

Yeah, the paths you give on the cmdline are the same as the recursion roots (R).

[ThomasWaldmann]

Docs fixed by #6242 and #6265.

[jefft]

This was confusing to me too. It seems natural for relative path patterns to be relative to the nearest root, allowing things like:

R /path/to/app
- logs/*.log

The confusing part in the docs is the sentence "Borg always stores all file paths normalized and relative to the current recursion root". In the example above, the recursion root is /path/to/app, and "relative to" that would be e.g. logs/stdout.log.

Rather, the docs should say "Borg always store all file paths normalized and relative to the first directory in the current recursion root". So /path/to/app/logs/stdout.log is stored as path/to/app/logs/stdout.log. I've attached a PR.

Anyhow, I hope relative includes/excludes can be supported one day.

[jefft]

Also, in the docs, the sentence "If you give ../../relative as root, the paths will be normalized as relative/." seems wrong:

root@jturner-desktop # mkdir -p /tmp/app/logs
root@jturner-desktop # date > /tmp/app/logs/stdout.log
root@jturner-desktop # cd /tmp/app
root@jturner-desktop /tmp/app # borg create --dry-run --list -v  test-{now} ../app --pattern '- app/logs/stdout.log'
+ ../app/logs/stdout.log
+ ../app/logs
+ ../app

This might be a bug though. No path normalization is being done (in 2.0.0b6 anyway). I can get the exclude to work with:

root@jturner-desktop/tmp/app # borg create --dry-run --list -v  test-{now} ../app --pattern '- ../app/logs/stdout.log'
- ../app/logs/stdout.log
+ ../app/logs
+ ../app

[ThomasWaldmann]

At create time, borg outputs the paths starting with the recursion root. But if you look into the archive (borg list), you should see app/....

Guess the exclude behaviour needs checking, that looks unexpected.

[ThomasWaldmann]

I just check current master branch code and it also behaves like seen in #6231 (comment) .

Also, 1.2-maint current code behaves the same.