-
-
Notifications
You must be signed in to change notification settings - Fork 837
Description
Have you checked borgbackup docs, FAQ, and open GitHub issues?
Yes
Is this a BUG / ISSUE report or a QUESTION?
Bug
System information. For client/server mode post info for both machines.
Your borg version (borg -V).
borg-2.0.0b5
Operating system (distribution) and version.
Arch Linux, Ubuntu Server 22.04
Hardware / network configuration, and filesystems used.
Local Borg repositories for testing, ext4
How much data is handled by borg?
A few GB, for testing
Full borg commandline that lead to the problem (leave away excludes and passwords)
$ borg-2.0.0b5-linuxnew64 delete --repo /path/to/testrepo1 --cache-only --verbose
Enter passphrase for key /mnt/HDD/scratch/testrepos/testrepo1:
Aborting: if you really want to delete all archives, please use -a 'sh:*' or just delete the whole repository (might be much faster).
Describe the problem you're observing.
Expected behavior:
From the docs and from the name of the switch I would expect that borg would clean the cache, i.e. delete the files cache and/or delete the chunks cache and/or delete the contents of chunks.archives.d. It should not delete or modify stored archives.
Observed behavior:
Borg refuses to run when no --match-archives switch is also given. There is different behavior, depending on the value of this parameter:
--cache-only --match-archives 'id:some-not-existing archive': nothing gets deleted (as the archive does not exist), cache files have same size as before. No deletion of cache.--cache-only --match-archives 'id:some-existing archive': archive gets deleted, cache files have same size as before. No deletion of cache.--cache-only --match-archives 'sh:*: repo is empty afterwards, chunks cache is small (empty?), files cache remains.
In my opinion this is a bug, as it violates the "principle of least surprise". If an option switch says "cache-only", then it should operate only on the cache. On the other hand, if this switch is supposed to somehow only delete the cache for the archives specified with --match-archives, then this behavior should be documented much more extensively.