From: Fabian Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [pve-devel] [PATCH manager] fix maxfiles behavior
Date: Mon, 9 Nov 2020 09:56:33 +0100 [thread overview]
Message-ID: <20201109085633.12688-1-f.ebner@proxmox.com> (raw)
Commit 5ba2a605ac14de58572f7b8d6e04b45b34724b0a hard-coded 0 as the default
for maxfiles in the --storage case, but the actual default should be the
value from read_vzdump_defaults(), which obtains the value from
/etc/vzdump.conf or the VZDump schema if the value has not been modified in
that file. The initial default from the schema is 1, not 0.
Tested on PVE 6.1 to verify that behavior.
Move the sanity check for zero-ness to where we have the final value for
maxfiles. Like this, we also have an implicit definedness check and more
importantly, it is more future-proof in case we ever allow maxfiles 0 in the
VZDump schema itself.
Also, force conversion to int to be extra safe.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
---
@Stefan: I wasn't able to trigger a warning about using '== 0' on a non-number type,
the only thing I can get is:
Use of uninitialized value in numeric eq (==)
Does this patch work with your use case as well or is there something off?
PVE/VZDump.pm | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/PVE/VZDump.pm b/PVE/VZDump.pm
index 517becb1..40a5a035 100644
--- a/PVE/VZDump.pm
+++ b/PVE/VZDump.pm
@@ -474,11 +474,7 @@ sub new {
if (!defined($opts->{'prune-backups'}) && !defined($opts->{maxfiles})) {
$opts->{'prune-backups'} = $info->{'prune-backups'};
- $opts->{maxfiles} = $info->{maxfiles} // 0;
- if ($opts->{maxfiles} == 0) {
- # zero means keep all, so avoid triggering any remove code path to be safe
- $opts->{remove} = 0;
- }
+ $opts->{maxfiles} = $info->{maxfiles};
}
}
} elsif ($opts->{dumpdir}) {
@@ -490,7 +486,13 @@ sub new {
if (!defined($opts->{'prune-backups'})) {
my $maxfiles = delete $opts->{maxfiles} // $defaults->{maxfiles};
- $opts->{'prune-backups'} = { 'keep-last' => $maxfiles } if $maxfiles;
+ $maxfiles = int($maxfiles); # shouldn't be necessary, but be safe
+ if ($maxfiles) {
+ $opts->{'prune-backups'} = { 'keep-last' => $maxfiles };
+ } else {
+ # maxfiles being zero means keep all, so avoid triggering any remove code path to be safe
+ $opts->{remove} = 0;
+ }
}
if ($opts->{tmpdir} && ! -d $opts->{tmpdir}) {
--
2.20.1
next reply other threads:[~2020-11-09 8:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-09 8:56 Fabian Ebner [this message]
2020-11-09 9:58 ` Stefan Reiter
2020-11-16 17:21 ` [pve-devel] applied: " Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201109085633.12688-1-f.ebner@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox