[pbs-devel] [PATCH v3 pxar 3/6] format: add helper type ContentRange

[Turkijan]

Hi, How can I download latest proxmox backup server repository ?
I've faced issue during building because current proxmox-sys is using old
version of rust.
[image: image.png]
proxmox-sys 0.5.5 is not latest?

On Wed, Jun 12, 2024 at 2:27 AM Fabian Grünbichler <
f.gruenbichler at proxmox.com> wrote:

> 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 <c.ebner at proxmox.com>
> > ---
> > 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<u64>,
> > +    // Optional payload ref
> > +    pub(crate) payload_ref: Option<PayloadRef>,
>
> 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 at lists.proxmox.com
> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
> >
> >
> >
>
>
> _______________________________________________
> pbs-devel mailing list
> pbs-devel at lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pbs-devel/attachments/20240612/57055867/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 259210 bytes
Desc: not available
URL: <http://lists.proxmox.com/pipermail/pbs-devel/attachments/20240612/57055867/attachment-0001.png>