Questions about binary deltas and an internal error

Hello,

First, thanks again for dar!  This is a fantastic program.

So I have long been using dar in this scenario:

1. I generate a backup, piped to stdout, on the machine being backed up.
I use --aux to save a catalog for future reference, and use it for the
next time.

2. I use NNCP to transfer this to my backup machine, which, depending on
the backup, may be fully or nearly airgapped.  In either case, no live
access to it exists.

3. The backup is piped to dar --sequential-read for processing.

I have recently migrated some systems from previously using ZFS to
environments where ZFS isn't possible; thus, dar.  I was getting 10GB
deltas daily.

So I thought using delta sigs might be as easy as upgrading dar and
adding --delta sig (and maybe --include-delta-sig "*") to it.  But, no
dice.  I still have 10GB deltas.

Well, why?  I scratched my head for awhile, even tried making a brand
new full backup with --delta-sig from which to base the others on.  Then
I noticed this comment:

"Delta signature transfer is not possible for on-fly isolation"

Well, rats.

So, I thought, well I could use the program "pee" (from moreutils; like
tee, but each argument is a pipe rather than a file).  I figure I could
pipe it to:

dar --sequential-read -A - -C new... --delta sig --include-delta-sig "*"

But then I see that this might not work either, because:

"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.

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!

John