Keeps the behavior consistent with what happens for storages. It also
is required to not get into conflict with the check in archive_remove,
i.e. pruning here marks a backup as 'remove' and then archive_remove
complains that it's protected.
Signed-off-by: Fabian Ebner <f.eb...@proxmox.com>
---
I'm noticing now that old manager + new storage will still have the
problem with the added protection check in archive_remove. Is that
considered to be breaking? Can only be triggered by making use of
the new feature (or if .protected files were already present...),
but it would potentially affect scenarios where
vzdump --storage name
vzdump --dumpdir /path/for/name/dump
are used in parallel.
Dependency bump for pve-storage needed.
PVE/VZDump.pm | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
index d00be8b2..a5a956c8 100644
--- a/PVE/VZDump.pm
+++ b/PVE/VZDump.pm
@@ -992,6 +992,13 @@ sub exec_backup_task {
my $pruned = 0;
if (!defined($opts->{storage})) {
my $bklist = get_backup_file_list($opts->{dumpdir}, $bkname);
+
+ for my $prune_entry ($bklist->@*) {
+ if (-e
PVE::Storage::protection_file_path($prune_entry->{path})) {
+ $prune_entry->{mark} = 'protected';
+ }
+ }
+
PVE::Storage::prune_mark_backup_group($bklist, $prune_options);
foreach my $prune_entry (@{$bklist}) {
--
2.30.2
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
