Re: Questions about binary deltas and an internal error

On 09/03/2023 01:29, John Goerzen wrote:
> Hello,

Hello John,

> 

[...]
> 
> "Delta signature transfer is not possible for on-fly isolation" >
[...]

> "delta signature transfer is not possible when the archive of reference
> is read in sequential mode"
> 
> So I was a little bit at a loss as to just when/how delta signatures can
> be used.  I guess I would need to have enough space locally to store a
> temporary copy of the entire backup, then isolate the catalog from it,
> then send it along?  I'm not sure I can really rely on having that much
> space available.

Well, you can also proceed to catalogue isolation at the backup 
destination host, assuming you have dar available there too.

> 
> BUT... it actually worked!  Maybe!  It generated delta-managed dar
> files.
> 
> But on extraction, I got:
> 
> ---- exception type = [BUG] ----------
> [source]
> #011File filesystem_tools.cpp line 573 : it seems to be a bug here
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0x13d) [0x7fe3c659311d]
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(+0xa5bd8) [0x7fe3c64f9bd8]
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar18filesystem_restore5writeEPKNS_10cat_entreeERNS0_Ut_ERbS6_S6_S6_+0x780) [0x7fe3c65aace0]
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar14filtre_restoreERKSt10shared_ptrINS_16user_interactionEERKNS_4maskES7_RKNS_9catalogueERKNS_4pathEbbbbbRNS_10statisticsES7_bNS_17comparison_fieldsEbbbRKNS_11crit_actionENS_23archive_options_extract7t_dirtyEbbRKSt3setINS_10fsa_familyESt4lessISN_ESaISN_EEb+0xf55) [0x7fe3c65c2d95]
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archive9i_archive10op_extractERKNS_4pathERKNS_23archive_options_extractEPNS_10statisticsE+0x3e9) [0x7fe3c65d69e9]
> #011stack dump : /lib/x86_64-linux-gnu/libdar64.so.6000(_ZN6libdar7archive10op_extractERKNS_4pathERKNS_23archive_options_extractEPNS_10statisticsE+0x122) [0x7fe3c653d3d2]
> #011stack dump : dar(+0x46bd3) [0x56396ff80bd3]
> #011stack dump : dar(+0x4f0d0) [0x56396ff890d0]
> #011stack dump : dar(+0x22b71) [0x56396ff5cb71]
> #011stack dump : /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fe3c6048d0a]
> #011stack dump : dar(+0x22cea) [0x56396ff5ccea]
> [most outside call]
> -----------------------------------
> 
> INTERNAL ERROR, PLEASE REPORT THE PREVIOUS OUTPUT TO MAINTAINER
> 
> That error is:
> 
>                  if(!patcher.has_patch_base_crc())
>                      throw SRC_BUG; // s_delta should have a ref CRC
> 
> This is dar 2.7.8 on Debian x86_64.
> 
> Are there other solutions?  Am I missing something here?

Thanks for feedback. I will have a deeper look at this soon, but it 
seems the generated backup does not hold the checksum for the file in 
the state it should have before applying the binary patch. Thus dar 
cannot check the file is in good status for applying the patch.

If you have a simple scenario of backup creation (with all options used) 
that leads to this condition at extraction time, it would help a lot.


> 
> Thanks!
> 
> John
> 

Thanks in advance,
Denis