Repository navigation
borg2: Allow comma-separated archive IDs in aid: matcher #10313
Description
The aid: archive match pattern currently matches exactly one archive ID. Multiple -a / --match-archives options are combined using AND semantics, so there is currently no convenient way to explicitly select multiple archives by their unique IDs.
For example, the following does not match either archive, since an archive cannot have both IDs:
$ borg2 repo-list -r /run/media/daniel/prometheus/Borg/ -a aid:8961fcf1 -a aid:466b7c4d
Command error: archive ID based match needs to match precisely one archive ID
Suggestion
Allow aid: to accept a comma-separated list of archive IDs, with OR semantics within the pattern. All archive IDs given must still match exactly one archive.
For example:
$ borg2 repo-list -r /run/media/daniel/prometheus/Borg/ -a aid:8961fcf1,466b7c4d
8961fcf1 Mon, 2026-08-24 11:24:32 +0200 Tuxedo-InfinityBook-14 daniel Tuxedo-InfinityBook-14 Arch Linux (Last Update: 2026-08-20T00:1
466b7c4d Tue, 2026-08-25 12:21:14 +0200 Tuxedo-InfinityBook-14 daniel Tuxedo-InfinityBook-14 Arch Linux (Last Update: 2026-08-24T15:4
This could retain the current behavior for a single ID while providing a simple way to explicitly select multiple known archives.
Benefits
This would
- allow explicitly selecting multiple unique archives,
- avoid requiring multiple matcher options with different semantics,
- make
aid:more useful for scripts and other programmatic archive selection, - allow processing multiple explicitly selected archives in a single
borg2invocation instead of runningborg2separately for each archive, which can reduce overall runtime.
Activity
PhrozenByte commentedon Sep 2, 2026
tags:patterns already support comma-separated tags, but these are matched with AND semantics within a single pattern. Since this syntax is currently undocumented (docs use-a 'tags:TAG1' -a 'tags:TAG2'as example), we could change the semantics to OR without breaking documented behavior. AND semantics can still be achieved with multiple separate patterns, so having AND semantics within a single pattern is redundant.Neither
user:,host:, nordate:support comma-separated values yet, though. As a future enhancement, it might be reasonable to add the same behavior there as well.For name patterns, comma-separated alternatives would be a little hard to get right due to the different pattern styles (and with
re:patterns, one can already achieve this), so I wouldn't support them there. If things get that complicated, one should probably use tags instead; giving users this flexibility is exactly what they're for.These changes could be implemented together or separately; I can open separate issues for them if desired.
connect-aima commentedon Sep 7, 2026
@PhrozenByte Hi, I'd like to work on this issue. I'll investigate how archive match patterns are currently parsed and prepare a PR for supporting comma-separated archive IDs in aid: patterns.