On 09.11.20 09:56, Fabian Ebner wrote: > 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.eb...@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(-) > >
applied, thanks! But I really want tests for this after the releases... _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
