From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 7A4BD98CAA for ; Mon, 13 Nov 2023 16:36:31 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 5289A151CD for ; Mon, 13 Nov 2023 16:36:01 +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 ; Mon, 13 Nov 2023 16:36:00 +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 7D44341E44 for ; Mon, 13 Nov 2023 16:36:00 +0100 (CET) Date: Mon, 13 Nov 2023 16:35:53 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Christian Ebner , Proxmox Backup Server development discussion References: <20231109184614.1611127-1-c.ebner@proxmox.com> <1699880752.fodcayz7zn.astroid@yuna.none> <1419587687.3325.1699888493974@webmail.proxmox.com> In-Reply-To: <1419587687.3325.1699888493974@webmail.proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1699889467.nhdkcuuw11.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.066 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] [PATCH-SERIES v4 pxar proxmox-backup proxmox-widget-toolkit 00/26] fix #3174: improve file-level backup X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2023 15:36:31 -0000 On November 13, 2023 4:14 pm, Christian Ebner wrote: > Thanks for your comments, some thoughts inline: >=20 >> On 13.11.2023 15:23 CET Fabian Gr=C3=BCnbichler wrote: >> some (high-level) comments focused on compatibility: >>=20 >> the catalog v2 format is used unconditionally at the moment. IMHO it >> should be guarded/opt-in via --change-detection-method, since old >> clients cannot parse it. >=20 > While it is true that the new catalog format is not readable by an old cl= ient, > the motivation to include this unconditionally was to be able to also use > backups created with the default change detection mode as reference. > Backups with the change detection mode set to metadata would still not be > readable by older clients. >=20 > I can of course make this conditional and only ever use catalogs with for= mat > version 2 as reference in cases of metadata based file change detection. IMHO the downside of requiring two runs for the change-detection to become effective (which is the case for new groups anyhow) is far smaller than unconditionally breaking all catalog-related features for older clients with no way of opting out. especially since some of those features are server-side (file browsing/download for unencrypted backups, for example), and you might have a mix of clients accessing a PBS repo. the first run that just changes the catalog format to support subsequent runs could easily detect and log this state prominently to avoid confusion.