vzdump: fix regression with keep forever logic

fixes commit f354fe47fcaa51002e385ab132760e202a81279c, which changed
the logic to the newer storage prune helpers, but those are designed
in the spirits of PBS, with a keep-option not set meaning to keep
none.

This does not respects the storage special handling of maxfiles.
While in the API/CLI that option must be > 0m in can be zero when set
in a storage configuration entry, and then it means keep all. So, set
the internal remove option to false if that special condition is met.

This would have been a clearer, and less prone to changes,
implementation to begin with.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>

diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
index 4779c10e5d765c898633db26457d403701d4c5a0..6873ceafa847f9dee742daff0d3f94c057c8d6b9 100644 (file)
--- a/PVE/VZDump.pm
+++ b/PVE/VZDump.pm
@@ -475,6 +475,10 @@ sub new {
            if (!defined($opts->{'prune-backups'}) && !defined($opts->{maxfiles})) {
                $opts->{'prune-backups'} = $info->{'prune-backups'};
                $opts->{maxfiles} = $info->{maxfiles};
+               if ($opts->{maxfiles} == 0) {
+                   # zero means keep all, so avoid triggering any remove code path to be safe
+                   $opts->{remove} = 0;
+               }
            }
        }
     } elsif ($opts->{dumpdir}) {