From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <g.goller@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id DAD07B8232 for <pbs-devel@lists.proxmox.com>; Thu, 7 Mar 2024 10:22:52 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id BAB88336BA for <pbs-devel@lists.proxmox.com>; Thu, 7 Mar 2024 10:22:52 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pbs-devel@lists.proxmox.com>; Thu, 7 Mar 2024 10:22:50 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id ADBA748839 for <pbs-devel@lists.proxmox.com>; Thu, 7 Mar 2024 10:22:50 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 07 Mar 2024 10:22:49 +0100 Message-Id: <CZNEPKLCOFTE.2T7529VVKOCPF@proxmox.com> From: "Gabriel Goller" <g.goller@proxmox.com> To: "Christian Ebner" <c.ebner@proxmox.com>, "Proxmox Backup Server development discussion" <pbs-devel@lists.proxmox.com> X-Mailer: aerc 0.17.0-37-g3aa8b6308482-dirty References: <20240306143422.114335-1-g.goller@proxmox.com> <1800721063.9375.1709738015138@webmail.proxmox.com> In-Reply-To: <1800721063.9375.1709738015138@webmail.proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.095 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pbs-devel] [RFC proxmox-backup 0/3] Encode creation parameters into pxar archive X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 07 Mar 2024 09:22:52 -0000 Thanks for the review! On Wed Mar 6, 2024 at 4:13 PM CET, Christian Ebner wrote: > Wouldn't it make sense to extend the pxar file format by a dedicated > entry type to store such information? And handle these entries in a > dedicated manner? E.g. by a `PXAR_CLI_PARAMS` entry header? I though about this but disregarded it ultimately because of the whole=20 version update and backwards compat hassle. IMO this is 'debug data'=20 and 'extra information' so it would fit better inside the archive (same as the exclude-patterns, these are also not really important after the=20 archive has been created (except for debugging)). If for some reason=20 this data is missing it wouldn't be a problem at all. > While this approach has already been used up until now for storing the > pxar cli exclude patterns, allowing to encode such metadata inside the > archive as regular file without having any means other than the filename > to find and distinguish this information from other files seems not > ideal to me. We could also specify some kind of prefix for pxar-specific files, something like '.pxar_***'? This way we stay consistent and users can distinguish manually encoded files from their files. But I also get your point about having regular files appear in the pxar archive could be confusing to some. And obviously having 3+ of these files is a no-go. > This would of course require an updated pxar format version 2, which we > might need anyways if the patches regarding metadata based change > detection should be applied. Although this is a good point, if we merge both series in the same window, we would only have to do one update!=20 For some reason=E2=80=94now that I am writing this obviously=E2=80=94I am c= urrently more inclined to your version. Mostly because the `.pxarexclude` file also allows input (e.g. the user can create the file insert stuff), while=20 the `.pxar_creation_params` does not allow input and would have to=20 overwrite/ignore an existing file. I am open to other suggestions/inputs!