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

Turkijan turkijan083 at gmail.com
Wed Jun 12 13:37:13 CEST 2024


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.
error: no method named 'is_terminal' found for struct 'Stdin' in the
current scope
---> /usr/share/cargo/registry/proxmox-sys-0.5.5/src/linux/tty.rs:96:15

I think we're using old proxmox backup registry. How to do it?


On Wed, Jun 12, 2024 at 4:34 AM Turkijan <turkijan083 at gmail.com> wrote:

> 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/7ba034eb/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/7ba034eb/attachment-0001.png>


More information about the pbs-devel mailing list