<div dir="ltr">Hi, How can I download latest proxmox backup server repository ?<div>I've faced issue during building because current proxmox-sys is using old version of rust.</div><div>error: no method named 'is_terminal' found for struct 'Stdin' in the current scope</div><div>---> /usr/share/cargo/registry/proxmox-sys-0.5.5/src/linux/tty.rs:96:15</div><div><br></div><div>I think we're using old proxmox backup registry. How to do it?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2024 at 4:34 AM Turkijan <<a href="mailto:turkijan083@gmail.com">turkijan083@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi, How can I download latest proxmox backup server repository ?<div>I've faced issue during building because current proxmox-sys is using old version of rust.<br><img src="cid:ii_lxbr7bf90" alt="image.png" width="562" height="387"><br></div><div>proxmox-sys 0.5.5 is not latest?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2024 at 2:27 AM Fabian Grünbichler <<a href="mailto:f.gruenbichler@proxmox.com" target="_blank">f.gruenbichler@proxmox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On June 12, 2024 10:23 am, Christian Ebner wrote:<br>
> The new `ContentRange` type will be used to store content ranges to<br>
> be used when accessing a pxar archive via the decoder, but with<br>
> additional payload reference information in order to be able to<br>
> perform additional consistency checks on these entries.<br>
<br>
this is only used in the accessor part, and is not really related to the<br>
format at all, so maybe let's move it there?<br>
<br>
> <br>
> Signed-off-by: Christian Ebner <<a href="mailto:c.ebner@proxmox.com" target="_blank">c.ebner@proxmox.com</a>><br>
> ---<br>
> changes since version 2:<br>
> - limit fields to be pub(crate) only<br>
> <br>
>  src/format/<a href="http://mod.rs" rel="noreferrer" target="_blank">mod.rs</a> | 11 +++++++++++<br>
>  1 file changed, 11 insertions(+)<br>
> <br>
> diff --git a/src/format/<a href="http://mod.rs" rel="noreferrer" target="_blank">mod.rs</a> b/src/format/<a href="http://mod.rs" rel="noreferrer" target="_blank">mod.rs</a><br>
> index 0648924..37ba99f 100644<br>
> --- a/src/format/<a href="http://mod.rs" rel="noreferrer" target="_blank">mod.rs</a><br>
> +++ b/src/format/<a href="http://mod.rs" rel="noreferrer" target="_blank">mod.rs</a><br>
> @@ -43,6 +43,7 @@ use std::fmt;<br>
>  use std::fmt::Display;<br>
>  use std::io;<br>
>  use std::mem::size_of;<br>
> +use std::ops::Range;<br>
>  use std::os::unix::ffi::OsStrExt;<br>
>  use std::path::Path;<br>
>  use std::time::{Duration, SystemTime};<br>
> @@ -844,3 +845,13 @@ pub(crate) fn check_payload_header_and_size(header: &Header, size: u64) -> io::R<br>
>  <br>
>      Ok(())<br>
>  }<br>
> +<br>
> +/// Stores a content range to be accessed via the `Accessor` as well as the payload reference to<br>
> +/// perform consistency checks on payload references for archives accessed via split variant input.<br>
> +#[derive(Clone)]<br>
> +pub struct ContentRange {<br>
> +    // Range of the content<br>
> +    pub(crate) content: Range<u64>,<br>
> +    // Optional payload ref<br>
> +    pub(crate) payload_ref: Option<PayloadRef>,<br>
<br>
then these don't need to be pub(crate) either.<br>
<br>
some higher level questions:<br>
- this is effectively an opaque type then (the caller of<br>
  `content_range` gets it, but can then only pass it to<br>
  `open_contents_at_range`)<br>
- the range is derived directly from the entry, there's no longer a way<br>
  to pass in arbitrary ranges<br>
- what is the difference w.r.t. safety compared to `contents`?<br>
<br>
related:<br>
- what about FileContentsImpl? it's returned by open_contents_at_range,<br>
  and takes an arbitrary range, should we instead give that ContentRange<br>
  as well while we're at it and breaking API?<br>
<br>
is there actually a use case for the unsafe interfaces above outside of<br>
our own code that would warrant splitting the new ContentRange-based<br>
(possibly safe?) interface from the unsafe "arbitrary Range" one? or<br>
should we stick to one, but allow creating arbitrary ContentRanges? a<br>
user that really wants to read an arbitrary range can then just not set<br>
a PayloadRef and thus skip the header check?<br>
<br>
> +}<br>
> -- <br>
> 2.39.2<br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> pbs-devel mailing list<br>
> <a href="mailto:pbs-devel@lists.proxmox.com" target="_blank">pbs-devel@lists.proxmox.com</a><br>
> <a href="https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel" rel="noreferrer" target="_blank">https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel</a><br>
> <br>
> <br>
> <br>
<br>
<br>
_______________________________________________<br>
pbs-devel mailing list<br>
<a href="mailto:pbs-devel@lists.proxmox.com" target="_blank">pbs-devel@lists.proxmox.com</a><br>
<a href="https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel" rel="noreferrer" target="_blank">https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel</a><br>
<br>
</blockquote></div>
</blockquote></div>