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 552238F00 for ; Fri, 1 Sep 2023 17:03:28 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 346F31747C for ; Fri, 1 Sep 2023 17:03:28 +0200 (CEST) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 1 Sep 2023 17:03:26 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B9FB240F4D for ; Fri, 1 Sep 2023 17:03:25 +0200 (CEST) Message-ID: Date: Fri, 1 Sep 2023 17:03:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: en-US To: Thomas Lamprecht , Proxmox Backup Server development discussion References: <20230901080210.26336-1-g.goller@proxmox.com> <321e5633-e35b-4dd5-8c0a-4e6eba33ca06@proxmox.com> From: Gabriel Goller In-Reply-To: <321e5633-e35b-4dd5-8c0a-4e6eba33ca06@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.335 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 NICE_REPLY_A -3.478 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com] Subject: Re: [pbs-devel] [PATCH proxmox-backup] fix #3921: client: confusing backup reader error 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: Fri, 01 Sep 2023 15:03:28 -0000 On 9/1/23 13:51, Thomas Lamprecht wrote: > Am 01/09/2023 um 10:02 schrieb Gabriel Goller: >> When using the catalog shell command, a common error is that user pass >> "./files.pxar" instead of "files.pxar". This will result in a cryptic error >> "... value does not match regex pattern ...". Added some context to the >> error according to suggestions here [1]. > adding error context can be good in general, but the specific case > mentioned could be also solved explicitly by either stripping ./ > or handling it explicitly. How does it handle multiple consecutive > slashes in paths? Like "foo///bar"? As that would need similar > normalizing so, if that works, then we maybe got already some place > where we can add handling for ./, and otherwise it might make sense > to start thinking about adding such things. We return the error above. We have this regex in place for all file-names: `PROXMOX_SAFE_ID_REGEX_STR { () => { r"(?:[A-Za-z0-9_][A-Za-z0-9._\-]*)" }; }` > As when multiple users run into some issue it might be warranted > to check if them "holding it wrong" should be actually a valid way > to hold it. I don't think so to be honest, because AFAIK we don't support directories in snapshots (?) so it doesn't make sense to pass "./test.pxar". Stripping is also wrong, because the . (dot) would be an accepted character in the file-name and thus we cannot remove it. Though we could remove every prohibited character (the / in this case) and the characters around (the . in our example)? >> [1]: https://bugzilla.proxmox.com/show_bug.cgi?id=3921 >> >> Signed-off-by: Gabriel Goller >> --- >> pbs-client/src/backup_reader.rs | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/pbs-client/src/backup_reader.rs b/pbs-client/src/backup_reader.rs >> index 2cd4dc27..138e836a 100644 >> --- a/pbs-client/src/backup_reader.rs >> +++ b/pbs-client/src/backup_reader.rs >> @@ -98,7 +98,10 @@ impl BackupReader { >> pub async fn download(&self, file_name: &str, output: W) -> Result<(), Error> { >> let path = "download"; >> let param = json!({ "file-name": file_name }); >> - self.h2.download(path, Some(param), output).await >> + self.h2 >> + .download(path, Some(param), output) >> + .await >> + .map_err(|err| format_err!("http2 file download '{}' failed: \n{}", file_name, err)) > please use captured identifiers for new format!/format_err! et al. > calls, e.g., here: > > .map_err(|err| format_err!("http2 file download '{file_name}' failed - {err}")) > > We also normally do not use a newline to separate prefix from actual > error, or would there be a good reason to deviate from the norm here? Yes, because the `err` is a multi-line string here. On the api we have a `Vec` of errors and return it as a string using `\n` as a delimiter. >> } >> >> /// Execute a special GET request and send output to a writer