From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 1761D1FF391 for ; Wed, 12 Jun 2024 11:26:50 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 92B08BDC3; Wed, 12 Jun 2024 11:27:26 +0200 (CEST) Date: Wed, 12 Jun 2024 11:27:19 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox Backup Server development discussion References: <20240612082400.110789-1-c.ebner@proxmox.com> <20240612082400.110789-4-c.ebner@proxmox.com> In-Reply-To: <20240612082400.110789-4-c.ebner@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1718183169.l58jrsip6i.astroid@yuna.none> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.057 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 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [mod.rs, proxmox.com] Subject: Re: [pbs-devel] [PATCH v3 pxar 3/6] format: add helper type ContentRange 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: , Reply-To: Proxmox Backup Server development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" On June 12, 2024 10:23 am, Christian Ebner wrote: > The new `ContentRange` type will be used to store content ranges to > be used when accessing a pxar archive via the decoder, but with > additional payload reference information in order to be able to > perform additional consistency checks on these entries. this is only used in the accessor part, and is not really related to the format at all, so maybe let's move it there? > > Signed-off-by: Christian Ebner > --- > changes since version 2: > - limit fields to be pub(crate) only > > src/format/mod.rs | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/src/format/mod.rs b/src/format/mod.rs > index 0648924..37ba99f 100644 > --- a/src/format/mod.rs > +++ b/src/format/mod.rs > @@ -43,6 +43,7 @@ use std::fmt; > use std::fmt::Display; > use std::io; > use std::mem::size_of; > +use std::ops::Range; > use std::os::unix::ffi::OsStrExt; > use std::path::Path; > use std::time::{Duration, SystemTime}; > @@ -844,3 +845,13 @@ pub(crate) fn check_payload_header_and_size(header: &Header, size: u64) -> io::R > > Ok(()) > } > + > +/// Stores a content range to be accessed via the `Accessor` as well as the payload reference to > +/// perform consistency checks on payload references for archives accessed via split variant input. > +#[derive(Clone)] > +pub struct ContentRange { > + // Range of the content > + pub(crate) content: Range, > + // Optional payload ref > + pub(crate) payload_ref: Option, then these don't need to be pub(crate) either. some higher level questions: - this is effectively an opaque type then (the caller of `content_range` gets it, but can then only pass it to `open_contents_at_range`) - the range is derived directly from the entry, there's no longer a way to pass in arbitrary ranges - what is the difference w.r.t. safety compared to `contents`? related: - what about FileContentsImpl? it's returned by open_contents_at_range, and takes an arbitrary range, should we instead give that ContentRange as well while we're at it and breaking API? is there actually a use case for the unsafe interfaces above outside of our own code that would warrant splitting the new ContentRange-based (possibly safe?) interface from the unsafe "arbitrary Range" one? or should we stick to one, but allow creating arbitrary ContentRanges? a user that really wants to read an arbitrary range can then just not set a PayloadRef and thus skip the header check? > +} > -- > 2.39.2 > > > > _______________________________________________ > pbs-devel mailing list > pbs-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel > > > _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel