[pve-devel] [PATCH v4 manager 7/7] Always use prune-backups instead of maxfiles internally
Fabian Ebner
f.ebner at proxmox.com
Mon Aug 24 09:25:48 CEST 2020
Am 21.08.20 um 13:33 schrieb Thomas Lamprecht:
> On 09.07.20 14:45, Fabian Ebner wrote:
>> For the use case with '--dumpdir', it's not possible to call prune_backups
>> directly, so a little bit of special handling is required there.
>>
>> Signed-off-by: Fabian Ebner <f.ebner at proxmox.com>
>> ---
>> PVE/VZDump.pm | 42 ++++++++++++++++--------------------------
>> 1 file changed, 16 insertions(+), 26 deletions(-)
>>
>
> breaks having a max backup set on a storage, before this it complains, after
> this I can make as many backups I want..
>
Sorry, turns out it was a typo:
Am 09.07.20 um 14:45 schrieb Fabian Ebner:
> diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
> index 17153fe4..d87ef857 100644
> --- a/PVE/VZDump.pm
> +++ b/PVE/VZDump.pm
> @@ -484,8 +484,10 @@ sub new {
> die "internal error";
> }
>
> - if (!defined($opts->{'prune-backups'}) &&
!defined($opts->{maxfiles})) {
> - $opts->{maxfiles} = $defaults->{maxfiles};
> + if (!defined($opts->{'prune-backups'})) {
> + $opts->{maxfiles} //= $defaults->{maxfiles};
> + $opts->{'prune_backups'} = { 'keep-last' => $opts->{maxfiles} };
With 'prune-backups' here, it should work. Should I send a v5?
> + delete $opts->{maxfiles};
> }
More information about the pve-devel
mailing list