dar-discussions Mailing List for DAR - Disk ARchive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 13/01/2019 20:33, gulikoza via Dar-discussions wrote:
> Hi,

Hi,

> 
> 
> Thank you for pushing all the fixes.
> 
> Another observation, which I'm not sure if it's related...I'm
> getting a lot of notices in the log:
> 
> Failed resaving uncompressed the inode data ... Resaving
> uncompressed the inode data to gain space is not possible, keeping 
> data compressed ...
> 
> 
> A lot more than what was with version 2.5. Some files get the first
> warning, some files the second...I haven't really figured out why
> the messages are appearing and what is the difference between the
> two. Can this be related to delta signatures or might this be some
> other issue in 2.6?

Strange thing. Can you double check that you are using the same
compression masks (-Y, -Z options), the same --mincompr option and the
same compression algorithm?

There has been change only with lzo compression in 2.5.10 to match the
compression ratio used by lzop as described here:

http://dar.linux.free.fr/doc/FAQ.html#lzop_vs_dar

for the rest, 2.6.x use the same compression code as release 2.5.10
and above

You should not observe difference when doing full backup, though, when
doing a delta patch, dar tries to compress the delta patch (not the
binary signature which is usually much smaller). This may lead to the
phenomenon you observe which can be reduced by increasing --mincompr
option (but also impacts normal backup)

> 
>> From the code there doesn't seem to be anything terribly wrong
>> with the
> archive if this is hit, but it's still somewhat concerning when
> there are a lot of these Failed messages... especially when they
> didn't seem to appear before.

Yes, I understand this concern, we will look into this. Can you check
whether this concerns only delta patch operation done during
incremental/differential backup?

> 
> Thanks!
> 
> gulikoza
> 
> 

Regards,
Denis
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAlw8gx0ACgkQCDGwvQPY
sYIaBw//YfZTOcabfWAifE/rsKXIHwPUs/11LPLFWJvoj6JpLE2PzVWkDAaXGq5q
zj1Dvu5x77nSh+wxS/VRxOxdD/IfHN3XCw4ArloXrWZYPtE9lXyUnznZa5mFbaI/
EweOBAkWANXbiBXJA2fVu8QrLAdd7bMLBhBnSWLY+oLhLPLxytQoJkjfI19r41zx
mRwci9X7whPJsISgjv7XUTCgWhl/WIFBBBlcxt4bXlacFHxrR2PzIHKKqyo8qlKe
HWvrvQvagb9FtAsD8kodjzeNngn2CxHRMIPZVy9SHV5Vc6sB1dqEQ7E8UK6BIkNc
EsDQQSBl3c9LEp66lBWopNAyLi/+uHRLNhukbnBjOStZTOLJgVHqL62ghagxTAg6
Vcf2ZvUvupKiED1jg/8Rd+IsLMOMIu4ARV2VSZw0X0dkW9JB4NRaUyOTlXBOLlLD
YA7Jj/a3TYlvx7sNroBjivxwr6RkGJP3id1fdev3y3q6VajlsPUTg9xOVswdGgQR
YcXV2E5V21ZcSh8qmzg6hZAkB0OVqtBJJkooM5GZIUYLOY0kPzs3LtMsCO6ZCWj1
2eau/VVtYpKSA35ImuafXqxORCECugjF3dAGeWSJHjG3C3rBI9izY2NHlAM9NuLt
gOqKWze1pl3VuuqbbX2mMGzElOlrM7OMKqW8eWyty2NlRW4kzFI=
=cHim
-----END PGP SIGNATURE-----

Hi,


Thank you for pushing all the fixes.

Another observation, which I'm not sure if it's related...I'm getting a lot
of notices in the log:

Failed resaving uncompressed the inode data
...
Resaving uncompressed the inode data to gain space is not possible, keeping
data compressed
...


A lot more than what was with version 2.5. Some files get the first warning,
some files the second...I haven't really figured out why the messages are
appearing and what is the difference between the two. Can this be related to
delta signatures or might this be some other issue in 2.6?

>From the code there doesn't seem to be anything terribly wrong with the
archive if this is hit, but it's still somewhat concerning when there are a
lot of these Failed messages... especially when they didn't seem to appear
before.

Thanks!

gulikoza

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/12/2018 21:26, gulikoza via Dar-discussions wrote:
> Hi Denis,
> 

Hi Gulikoza,

> 
> 
> 
> 
> Congratulations on dar 2.6 release :-)
> 

Thanks!

> 
> 
> Thank you for all your hard work all these years!
> 
> I really enjoy working with dar, especially because of your
> attention to detail which makes dar very versatile tool.
> 
> 
> 
> Unfortunately I didn’t really have the time yet to test the binary
> delta feature before the final 2.6.0 release, but it’s just in time
> to make my yearly full backups with the signatures now and start
> testing binary deltas on production, haha ;-)

No problem. By the way, I've noted an important memory consumption
when using delta signatures, more than expected. I'm currently trying
to figure out whether reducing that memory footprint is possible and how
.

So to workaround that possible problem in the meanwhile, you should as
much precisely as possible specify the files to consider for binary
delta by mean of --include-delta-sig / --exclude-delta-sig options.

> 
> 
> 
> Just to let you know, there is an issue compiling dar 2.6 in RHEL-7
> due to gcc 4.8.5:
> 
> 
> 
> In file included from i_archive.hpp:35:0,
> 
> from archive.cpp:31:
> 
> erreurs.hpp:110:15: error: function 'libdar::Egeneric::niveau& 
> libdar::Egeneric::niveau::operator=(libdar::Egeneric::niveau&&)' 
> defaulted on its first declaration with an exception-specification
> that differs from the implicit declaration
> 'libdar::Egeneric::niveau& 
> libdar::Egeneric::niveau::operator=(libdar::Egeneric::niveau&&)'
> 
> niveau & operator = (niveau && ref) noexcept = default;
> 
> …
> 
> (^ and so on, basically all the prototypes with noexcept =
> default)

OK, I will look into this, thanks for feedback!

> 
> 
> 
> I understand that gcc 4.8.5 has a very limited (buggy) support for 
> c++11, but unfortunately I guess this means dar 2.6 will not be 
> available in EPEL-7.

Correct, it will be difficult, as dar strongly rely on some features
brought by C++11 and C++14, like move operator, smart pointers and
several other things that reduce memory footprint and/or CPU cycle.

> 
> It should probably also be stated in the documentation that gcc 4.8
> is no longer supported (if this was the intention).

The oldest gcc I've tested dar/libdar with is gcc 4.9 and it compiles
fine without even a warning :-) so I will upgrade the documentation
accordingly, thanks for this feedback.

> 
> 
> 
> I was able to compile it with devtoolset-7 (gcc 7.3.1), create a
> RPM (along with statically linked libthreadar) and the resulting
> RPM seems to work fine for now on vanilla Centos 7 (without the
> newer gcc and libs> installed).

OK, good!

> 
> 
> 
> Looking forward, I see that dar is using RS_DEFAULT_BLOCK_LEN which
> is just 2048 bytes. If the signatures will be switched to Blake2,
> this means the signature will be 36 bytes (256-bit blake2 + 4 bytes
> crc32) for each 2k block. This might be a bit too much for larger
> files and I was thinking that instead of having (yet another)
> command line option for that, dar might try to optimize the
> block_len based on file size. I don’t see the need for 2k
> signatures on multi-gigabyte files, where 8k or 16k signature might
> be just ok and a lot smaller. I have a proof of concept patch for
> that already, for instance with the 2GB file the blake2 catalog
> size is reduced from 36MB to 9MB with 8k blocks (default dar
> catalog with md4 signature would be around 18MB for the same
> file).

Well, reducing the size of signature more than it is already would
increase the risk of collision (unnoticed difference, ...), for that
reason I would rather let the user decide (yes, by adding a new option
...)

> I can send the patch to github if needed ;-)>
> 
> 
> And to nitpick a bit, the man page is not mentioning [Delta] in
> the [data] displayed fields. :-)

Oops, must fix that! Thanks!

> 
> 
> 
> 
> 
> Thanks again and Happy Holidays!

Thanks, Happy new year and I hope the Holidays were good to you too :-)

> 
> 
> 
> Regards,
> 
> gulikoza
> 

Regards,
Denis

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEOzEprx3d76WjfYGPCDGwvQPYsYIFAlwzfQgACgkQCDGwvQPY
sYLyxw/+JwP7IT5FJUnLyIkWnuv8xcBiPe5qg6cQLTFr7s2SK6M66lhxOBuHLU8h
aK7pVTaQDqf9b04sPw5CuuZ4Sb6PfzXNE3lX4+tG7daErzquoZoX73R7VN4xGeRW
n6YV0DtBZqbmWIyt8KhUwilQOkNCNmGdZAkhCY5E2YjPGJthQFJQv+DAGX7Fy2Cw
spvFu4K9EKcYAhMwcaQP4x/EH0MEEWF2d8sfAXeOmkKYgbonImDwJtn/03VOsGt2
HIrIVIoERAEd7CaJZHKltCJMu+QFEUkkhQbhGGVT1lX2MJqITM//ZW65f1net0H7
MUAVAvLcjlR1bz1zPBZadoz0baCOtcT9ObF4n/ndXfxruOUy4+jNeeY3eahG76wQ
0ZwMBZ1uDwnrtEg/3A4TF5adknQ7PFKAfg6SPlgrmppgaSSEtNVpp/KgiFhGKrG8
kNfPj868T8azitMIK7SgreVi7Z9CXF6cCbthTtsZFEPBhjErGP3IuWu8Ve4Fgy8Y
EFw/BZt0Rv07s6fYf1o+FiNypHnujThfDP7bQbsI1qOA2VQz5+8K5YMdXJBBnhqI
u8X/LId1EEEtEbo6llsj+wfdzsH3c2yX9YneFMwniE718nLmGvv3sVQgqFMwVMkb
3iUY8QQ0k6JZvppduSlwTbBP5gfGzDa/tIYTHpvuO4QbLWf2rSw=
=kR1R
-----END PGP SIGNATURE-----

Hi Denis,

 

 

Congratulations on dar 2.6 release :-)

 

Thank you for all your hard work all these years!

I really enjoy working with dar, especially because of your attention to
detail which makes dar very versatile tool.

 

Unfortunately I didn't really have the time yet to test the binary delta
feature before the final 2.6.0 release, but it's just in time to make my
yearly full backups with the signatures now and start testing binary deltas
on production, haha ;-)

 

Just to let you know, there is an issue compiling dar 2.6 in RHEL-7 due to
gcc 4.8.5:

 

In file included from i_archive.hpp:35:0,

                 from archive.cpp:31:

erreurs.hpp:110:15: error: function 'libdar::Egeneric::niveau&
libdar::Egeneric::niveau::operator=(libdar::Egeneric::niveau&&)' defaulted
on its first declaration with an exception-specification that differs from
the implicit declaration 'libdar::Egeneric::niveau&
libdar::Egeneric::niveau::operator=(libdar::Egeneric::niveau&&)'

      niveau & operator = (niveau && ref) noexcept = default;

.

(^ and so on, basically all the prototypes with noexcept = default)

 

I understand that gcc 4.8.5 has a very limited (buggy) support for c++11,
but unfortunately I guess this means dar 2.6 will not be available in
EPEL-7.

It should probably also be stated in the documentation that gcc 4.8 is no
longer supported (if this was the intention).

 

I was able to compile it with devtoolset-7 (gcc 7.3.1), create a RPM (along
with statically linked libthreadar) and the resulting RPM seems to work fine
for now on vanilla Centos 7 (without the newer gcc and libs installed).

 

Looking forward, I see that dar is using RS_DEFAULT_BLOCK_LEN which is just
2048 bytes. If the signatures will be switched to Blake2, this means the
signature will be 36 bytes (256-bit blake2 + 4 bytes crc32) for each 2k
block. This might be a bit too much for larger files and I was thinking that
instead of having (yet another) command line option for that, dar might try
to optimize the block_len based on file size. I don't see the need for 2k
signatures on multi-gigabyte files, where 8k or 16k signature might be just
ok and a lot smaller. I have a proof of concept patch for that already, for
instance with the 2GB file the blake2 catalog size is reduced from 36MB to
9MB with 8k blocks (default dar catalog with md4 signature would be around
18MB for the same file). I can send the patch to github if needed ;-)

 

And to nitpick a bit, the man page is not mentioning [Delta] in the [data]
displayed fields. :-)

 

 

Thanks again and Happy Holidays!

 

Regards,

gulikoza

> Yes but have you tried what I suggested?
Sorry but what did you suggest? I did fetch "a fresh unpacked source
tree" from GitHub. Maybe I didn't understand what you wanted
me to do.

> By the way, does dar-2.5.16 has the same problem on your
> installation?
Yes, exactly the same issue. "checking for iconv - yes", but linking fails.

wget 
ftp://ftp.dm3c.org/dar.linux.free.fr/Releases/Source_code/dar-2.5.16.tar.gz
tar xf dar-2.5.16.tar.gz
cd dar-2.5.16
misc/batch_cygwin dar-2.5.16 win64

gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: 
/cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0/configure 
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0 
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc 
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C 
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin 
--target=x86_64-pc-cygwin --without-libiconv-prefix 
--without-libintl-prefix --libexecdir=/usr/lib --enable-shared 
--enable-shared-libgcc --enable-static 
--enable-version-specific-runtime-libs --enable-bootstrap 
--enable-__cxa_atexit --with-dwarf2 --with-tune=generic 
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite 
--enable-threads=posix --enable-libatomic --enable-libcilkrts 
--enable-libgomp --enable-libitm --enable-libquadmath 
--enable-libquadmath-support --disable-libssp --enable-libada 
--disable-symvers --with-gnu-ld --with-gnu-as 
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix 
--without-libintl-prefix --with-system-zlib --enable-linker-build-id 
--with-default-libstdcxx-abi=gcc4-compatible 
--enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.3.0 (GCC)

find /cygdrive/c/cygwin64/ -name *iconv*

...
/cygdrive/c/cygwin64/bin/iconv.exe
...
/cygdrive/c/cygwin64/lib/libiconv.a
/cygdrive/c/cygwin64/lib/libiconv.dll.a
...
/cygdrive/c/cygwin64/usr/include/iconv.h
/cygdrive/c/cygwin64/usr/include/sys/iconvnls.h
/cygdrive/c/cygwin64/usr/share/aclocal/iconv.m4
...

If you have an up to date list of required cygwin packages, I can check
mine against it and install missing.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 03/09/2018 19:41, mannino wrote:
> 
>> can you try the following on a fresh unpacked source tree:
>> 
>> #cd dar-2.6.0.RC3 #misc/batch_cygwin 2.6.0.RC3 win64
>> 
>> this should build a zip package in the current directory.
> The following commands:
> 
> wget https://github.com/Edrusb/DAR/archive/master.zip unzip
> master.zip cd DAR-master misc/init misc/batch_cygwin 2.6.0.RC3
> win64
> 
> produce the same compilation error as before (duplicating it here
> for the sake of completeness):
> 

Yes but have you tried what I suggested?
By the way, does dar-2.5.16 has the same problem on your installation?

Cheers,
Denis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW42b0QgxsL0D2LGCAQj9yw/+KJ2fafYrK165MS01Cn+4a6I9yLGrOG7l
GkD92VRix9B704cIfJ6Rls6JUvXAniyy6+fLm8KvZkNDiVU6On7ud4eicSqMDq/I
qQXKPp9sPeBlxBIpnpc5KTJGjnOJh8NfOgTii22S+JSlT10E5FCVn6OYu3gV+a8+
CRtvsl2fXOUbQA1bkZIslh8GNL1qR3wlqfnjMxiDqI/oBaMQgaBYts73ox8h7juY
moO33bHtis/EnTdTJHBVLYTcOAMyemBNMaINe+uRXbCtu40xeluUUxWRIwIIyncK
ejUIx7+EhFVw4rpJtFGpsQd+GMb3IhM+5cOrxI3jSeMkP1GQFKo5DcLIN2MV9+1z
biyTH+IIlfsFld8exFSQsP7xU2hU2/Op/FympPVFwCh2MA8NwZ9LkZzQA5XLyUIF
doXGWD+S+AVdLTju/DV82h3NZ3oeBmhL0RxbbbmrYVyOa0GWkXKJaTrB5y3WQe7o
4ex9LxP5M/7Qv+DuFgV8WSpA9AF6xwKgeUHyuvFxx2fJs/s2UXp6VFn2I44mPZDK
P4cXoisFrd/VuDfGnLXb76ETnv5tHdTLQifIMm12S0UCxqbZkJduSVaXLO0fXfkV
4qVRQPbx+opv7oOQ21a3oqoA8JaLhkcWlcx5f8NiGWhi9YEcEnddbDWEpbz/AkVw
5XCiIgVo7Eo=
=Y6Kl
-----END PGP SIGNATURE-----

> can you try the following on a fresh unpacked source tree:
>
> #cd dar-2.6.0.RC3
> #misc/batch_cygwin 2.6.0.RC3 win64
>
> this should build a zip package in the current directory.
The following commands:

wget https://github.com/Edrusb/DAR/archive/master.zip
unzip master.zip
cd DAR-master
misc/init
misc/batch_cygwin 2.6.0.RC3 win64

produce the same compilation error as before (duplicating it here for
the sake of completeness):

---

libtool: link: g++ -static -o dar_static.exe command_line.o 
config_file.o dar.o dar_suite.o hide_file.o no_comment.o line_tools.o 
crit_action_cmd_line.o  -lintl ../libdar/.libs/libdar64.a -lpthread 
-lrsync -lgcrypt -lxxx -llzma -llzo2 -lbz2 -lz -ldl
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(dcigettext.o): 
In function `_nl_find_msg':
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1315: 
undefined reference to `libiconv'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1315:(.text+0x5ed): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1183: 
undefined reference to `libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1183:(.text+0x96f): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1177: 
undefined reference to `libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1177:(.text+0xaf9): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_open'
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(relocatable.o): 
In function `libintl_set_relocation_prefix':
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/relocatable.c:171: 
undefined reference to `libiconv_set_relocation_prefix'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/relocatable.c:171:(.text+0x46): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_set_relocation_prefix'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:574: dar_static.exe] Error 1
make[3]: Leaving directory '/cygdrive/d/DAR-master/src/dar_suite'
make[2]: *** [Makefile:424: all-recursive] Error 1
make[2]: Leaving directory '/cygdrive/d/DAR-master/src'
make[1]: *** [Makefile:466: all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/d/DAR-master'
make: *** [Makefile:398: all] Error 2
if test -z 'strip'; then \
   make  INSTALL_PROGRAM="/bin/sh /cygdrive/d/DAR-master/install-sh -c -s" \
     install_sh_PROGRAM="/bin/sh /cygdrive/d/DAR-master/install-sh -c 
-s" INSTALL_STRIP_FLAG=-s \
       install; \
else \
   make  INSTALL_PROGRAM="/bin/sh /cygdrive/d/DAR-master/install-sh -c -s" \
     install_sh_PROGRAM="/bin/sh /cygdrive/d/DAR-master/install-sh -c 
-s" INSTALL_STRIP_FLAG=-s \
     "INSTALL_PROGRAM_ENV=STRIPPROG='strip'" install; \
fi

---

I have tried a few more iconv-related cygwin packages but by now I don't
know what else to try and why it is refusing to compile yet saying
"checking for working iconv... yes".

Same thing with dar-2.6.0.RC3.tar.gz from your FTP.

I doubt this has any significance but I'm doing all this on Windows
Server 2012R2 x64 VPS.

NB: is this an unintentional typo to be corrected?
   can uses multiple threads : NO
s/uses/use/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 28/08/2018 22:26, Denis Corbin wrote:
> On 26/08/2018 22:10, mannino wrote:
>> On 26.08.2018 22:27, Denis Corbin wrote:
> 
> [...]
> 
>>> 
>>> this linking problem under Cygwin should be fixed with RC3, 
>>> available in GIT and on 
>>> ftp://ftp.dm3c.org/dar.linux.free.fr/Pre-releases
>> I am still getting the same error regarding gettext and iconv. 
>> The log is the same as in my first message:
> 
>>>> However, it then fails with inability to resolve iconv 
>>>> functions: ...>
>> Do you think it's a problem on my end?
> 
> this might be possible as I could build a dar64 package for windows
> (RC3) without problem... will double check tomorrow what message I
> get about iconv library.. just wonder whether iconv is still
> mandatory as it is more and more included in the standard C 
> library... for FreeBSD I guess it was not and iconv was necessary 
> but for Cygwin (?)
> 
> I will check also that my cygwin install is up to date, I guess so 
> but will double check that
> 
[...]

Sorry for the delay,

can you try the following on a fresh unpacked source tree:

#cd dar-2.6.0.RC3
#misc/batch_cygwin 2.6.0.RC3 win64

this should build a zip package in the current directory.

Cheers,
Denis


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW4voCAgxsL0D2LGCAQjdDRAAupZ0GGKlSqh9wd7+zBAZ7ieDysRoeQRv
A9+lQK+GQ19faeO3IyjcGk5Ndvikry2AJOkwsKkEK4tfMtkLL6rB0mXNctDB1Lsm
Ic3znCzT1MinNEn5NJ2OLUM+cKjjKsrINLkVakQzlHZmB7UioXGO+giZPWR7FESv
8uxxP/6KGi42d1qMpvEH66eY6OAZDjZq7ONvSN+x5PB6OR2rmd6ontqR2n8cz3WO
08VwPRk2ya9txeO6DcpDCAD/rDGzwZAW9IXTittGGiaF6ddgrAUWdSkmsYISAw+V
RcSthXU/AQv6bKPKJXUrJ4sjnAvmWMGfyjwdDDkJmCB/dGJyqOmRHUgMWFwPV18T
jLCcfc0jZLjGc0+J0Nz0WZppHkpHNpR8+L8jruWTcHbqRGSt235Zvrg/kPbiMa8J
4/yoipjqBoeGiVLK+zK+IbL0XSRHWBEU5ZwEOVTuBJxMeNAb7sDh4qxbh1lePRIo
YAUhDqV3EJoED5piOPFPAKddl0M/38QJ6uCpEzLdxr5ijeoe7okpQ1ZZdBH+18ED
Dm+rkemy3Z8LZS3/eGSLLuPkilGdtD4IYOrmE7Y0R6D8yYs7zgBfS8LJXbMkYzvb
uJwTm5FJPZAI25VVXlqiNHdDxpeQcuujD5IYzEU5DyfCPmVxdRj7O0EhM+QhgnPd
sdN0D8PZAmM=
=YfLn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 26/08/2018 22:10, mannino wrote:
> On 26.08.2018 22:27, Denis Corbin wrote:

[...]

>> 
>> this linking problem under Cygwin should be fixed with RC3, 
>> available in GIT and on 
>> ftp://ftp.dm3c.org/dar.linux.free.fr/Pre-releases
> I am still getting the same error regarding gettext and iconv. The
>  log is the same as in my first message:
> 
>>> However, it then fails with inability to resolve iconv 
>>> functions: ...>
> Do you think it's a problem on my end?

this might be possible as I could build a dar64 package for windows
(RC3) without problem... will double check tomorrow what message I get
about iconv library.. just wonder whether iconv is still mandatory as
it is more and more included in the standard C library... for FreeBSD
I guess it was not and iconv was necessary but for Cygwin (?)

I will check also that my cygwin install is up to date, I guess so but
will double check that

> dar configure seems to have no problem locating iconv:
> 
> ... checking for iconv... yes checking for working iconv... yes 
> checking how to link with libiconv... -liconv checking for GNU 
> gettext in libintl... yes checking whether to use NLS... yes 
> checking where the gettext function comes from... external libintl 
> checking how to link with libintl... -lintl checking for iconv... 
> (cached) yes checking for working iconv... (cached) yes checking 
> how to link with libiconv... -liconv checking for iconv 
> declaration... extern size_t iconv (iconv_t cd, char * *inbuf, 
> size_t *inbytesleft, char * *outbuf, size_t *outbytesleft); ...
[...]

Cheers,
Denis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW4WwCwgxsL0D2LGCAQhrZhAAmFnuFaBnHhTYO8jJiFugajmgt996dV2K
xF27eVCRNj7T1Wo0PT8U31cpSR5cIRxWw/c0sU8cuxPXWu8KTj8l7iMTUaOowH7z
9FfQuFo+KOczLMFBcYifaWR04QcBrWhTBx7307KA71EX6qSavf42XRkARG48kudU
TUSM/17QJkJ+rnbWMVbkrBpA8AM8+K30C3D74Gc+J6RZAFMl9S3FZ3N94J2zW1z3
X1bs9Gxp0FJnM8iRXBSrWYfdLoMQxh0A32WSWI5B0jaxh1eDTK9rVugPPeLJChT7
KXPixqZzCg4Fz6eLA2BJk/2rs8+8l5c3YgmiuAAg4/xMR3mwoX/7437EqNUonY/7
jp0Shoso764B8wzVfl/cmomOecVb8Cbx7cEy8JVNmpiG4Y4RCvYPghmqG6JZH+x/
aSY07WO20FVg4QeZe1BexIyBqzbhavdy4dmBMLxl31yF53HK3N49f4Be7ec17JdJ
Qaj0u5MxoCZrIvJJrQQcn5x7M58GQHRXtRG+dtDHQal8MczDtlfaVcPSsIODyDmO
Yh1x5FvYkl7jdUDw9ShDmaRNjLP0JmaTnBErVbohvFpO5mPn3iJCxnuBqnEbTSbe
5d5SWkbZS4Mc5fnFVNcbsAX57V8ZczPU0vV1jO8pZZTCUhbftCh5Whhjw6JECcyB
zEFLaEdub/8=
=QjLZ
-----END PGP SIGNATURE-----

On 26.08.2018 22:27, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> this linking problem under Cygwin should be fixed with RC3, available
> in GIT and on ftp://ftp.dm3c.org/dar.linux.free.fr/Pre-releases
I am still getting the same error regarding gettext and iconv. The log
is the same as in my first message:

>> However, it then fails with inability to resolve iconv functions:
>> ...

Do you think it's a problem on my end? dar configure seems to have no 
problem locating iconv:

...
checking for iconv... yes
checking for working iconv... yes
checking how to link with libiconv... -liconv
checking for GNU gettext in libintl... yes
checking whether to use NLS... yes
checking where the gettext function comes from... external libintl
checking how to link with libintl... -lintl
checking for iconv... (cached) yes
checking for working iconv... (cached) yes
checking how to link with libiconv... -liconv
checking for iconv declaration...
          extern size_t iconv (iconv_t cd, char * *inbuf, size_t 
*inbytesleft, char * *outbuf, size_t *outbytesleft);
...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

this linking problem under Cygwin should be fixed with RC3, available
in GIT and on ftp://ftp.dm3c.org/dar.linux.free.fr/Pre-releases

Regards,
Denis

On 23/08/2018 21:31, Denis Corbin wrote:
> Hi,
> 
> thanks for your feedback, will try to reproduce it and fix this
> 
> Best Regards, Denis
> 

[...]

> 
>> However, linking the binary fails with:
> 
>> libtool: link: g++ -static -o dar_static.exe command_line.o 
>> config_file.o dar.o dar_suite.o hide_file.o no_comment.o 
>> line_tools.o crit_action_cmd_line.o  -lintl 
>> ../libdar/.libs/libdar64.a -lpthread -lrsync -lgcrypt -lgpg-error
>>  -llzma -llzo2 -lbz2 -lz -ldl 
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/
l
>
>> 
d:
> 
> 
> 
> cannot find -lrsync
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/
l
>
>> 
d:
> 
> 
> 
> cannot find -lgcrypt
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/
l
>
>> 
d:
> 
> 
> 
> cannot find -lgpg-error
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/
l
>
>> 
d:
> 
> 
> 
> cannot find -llzma
>> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/
l
>
>> 
d:
> 
> 
> 

[...]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW4L/DQgxsL0D2LGCAQj3/xAAlzIxrEC298yR/Z8Yu1isOdSUm6cp3i1K
y7jlP8eQyI0R0+iy0ebnMK+QacsinUBEGrUKKPMBCXej+pU0i4BoD42mb9l7l/h3
1G8SM6Ev3JQVxn0rKROcwLPRGK3k4QY0qOH5nQzrxbJ9SAnqaKy55n6zCrnODYrc
slpMNcMPjiHRQfG18B7FsoPXu0HJb82rKb0CMchjwnBmLsy8MbHMQ6/AJvV13j9g
8vIsqVDc6BGB2YcUaJrE/xVy6RUpG+JopnaIcu3uYcvuFZMd5aye7gx2t3A2Qd7T
FUcjK4yl0hWvEoOQMJQYpkOtjLCURdbqrKXo0Mh7zJvH7+bfPBKb30xr27CkPXTb
z5Y5DJJYw7WcKTtDp+P9PNHXzz06SapMPGynYUjVq8R9ns0d36BNl398sSEcuLte
Wdz/nRXajB2wbrQ63/l+VIA/5khuo0SIxDQs75VGYNtuphH4HvsUoZwt27nxYzyt
uAqCzk09DU84Ank8JZtXsmJLDPyXgwHcEVHqvZRCsXgBsgLyG6hbSe4VxChyJVoo
NMDleSDQEDg9j0+JtHbIczspcelOU/F6XP6j5UT3F1RuCNuBcOWxDS2fV7MnMbl8
rMO4kSppPWHx2Z71E3lE5kPVrfG3gxwOjonU5BI0UzQZTPWzNgQq0mH1iGcxSrnM
r70sTzzYeZM=
=1fyy
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi


thank you for this feedback!

On 24/08/2018 07:48, mannino wrote:
> dar version from Ubuntu 18.04 packages when attempted to be used
> with an unsupported compression throws an exception during the
> cleanup:
> 
> Final memory cleanup... ---- exception type = [BUG] ---------- 
> [source] File wrapperlib.cpp line 337 : it seems to be a bug here

[...]

> 
> dar version 2.5.14-bis, Copyright (C) 2002-2052 Denis Corbin Long
> options support       : YES
> 
> Using libdar 5.12.1 built with compilation time options: Libz
> compression (gzip)      : YES Libbz2 compression (bzip2)   : YES 
> Liblzo2 compression (lzo)    : YES Liblzma compression (xz)     :
> NO     <<< NOTE THIS Strong encryption (libgcrypt): YES Public key
> ciphers (gpgme)   : YES Extended Attributes support  : YES Large
> files support (> 2GB)  : YES ext2fs NODUMP flag support   : YES 
> Special allocation scheme    : NO Integer size used            : 64
> bits Thread safe support          : YES Furtive read mode support
> : YES Linux ext2/3/4 FSA support   : YES Mac OS X HFS+ FSA support
> : NO Detected system/CPU endian   : little Posix fadvise support
> : YES Large dir. speed optimi.     : YES Timestamp read accuracy
> : 1 microsecond Timestamp write accuracy     : 1 microsecond 
> Restores dates of symlinks   : YES
> 
> compiled the Feb 17 2018 with GNUC version 7.3.0 dar is part of the
> Disk ARchive suite (Release 2.5.14-bis)
> 
> Command line:
> 
> dar -c ... -A... -@... -s... -zxz:6
> 
> When -zgzip:6 is used, it works fine. I'd expect a friendly error 
> telling compression method is unsupported (from -V) rather than an 
> exception.
> 
> Or is this an issue with the Ubuntu's package? (I don't currently 
> have access to another system to test it outside of Ubuntu.)
> 

this was no handling for that particular case (asking xz compression
while libxz is has not been linked with at compilation time), so libdar
hit a sanity check condition and triggered this error message.

2.6.0.RC2 is now available with fixes for that situation. I have also
checked for similar situation with other library libz, libbz2,
libcurl, libgpgme, and so on. Should be OK now.

I'm also working on the compilation problem under cygwin... keep you
informed.

Best Regards,
Denis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW4EXkggxsL0D2LGCAQgf8Q/9H3YXA9ABjXMBea+HCG28h5pc/YGzaodc
QsPvJZrIsjXRlqxqAqXfjF+LqGfsRirudokRPCsoGfR36flgDsVg1pEFBLHnGUOW
LRx9fB3uzS6t+0fTZ7iXzFYdXCFKhemZ2M72IyOm+Wjc8haSB0JwSUwSk3IJICyN
V39jxOmJ1l9OZ1QnYZz6b1p68alV5gEwTMChAzbONOM3WoMldGlLr38OiMRCn9/Q
Vh8PIS/Jn0v0Pyx/ODY+GHpPwx7WiYyD5o4n9Jq13hFLxiWmGZjXHtUegCmeQFTn
DIhC2P6FGsy8+Po5UE+2eMi1sJPV/dMebLlN5Eu02uT1iDjWQH/0G32xfUHS390M
yTE/0h74g+90wzhNKO+CDqCgLIo8usiABDgeJcbck90G+XJUHg6HHCWir60My33A
OrY14FafC16SMqqEu1O8vgW6yEthQtG3srb7Kpw7lmX7tyBHBbp98xWalDAsiYZA
FouS8Qf3mDuR4hxf5fsCr3QqRjxvpeh7YCnnFZRK4VuJ2X10UppBuKudaHRWXli8
q9MoUdxcgGGoQsWinn8ShCTVJCf+ThnOFl3plsTwD/FjgaFKunoBkP5MZa67mXjc
Ij/xnpG1WH184bR7HqFjwYHoY6jflBrbMD/djrzauv8gjm4isA6W91ElyGqtBfPU
400Oqwr+UZY=
=espY
-----END PGP SIGNATURE-----

dar version from Ubuntu 18.04 packages when attempted to be used with
an unsupported compression throws an exception during the cleanup:

Final memory cleanup...
---- exception type = [BUG] ----------
[source]
         File wrapperlib.cpp line 337 : it seems to be a bug here
         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar4EbugC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi+0xea) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar10wrapperlib15bz_compressInitEm+0x7c) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar10compressor4initENS_11compressionEPNS_12generic_fileEm+0x161) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar10compressorC2ENS_11compressionERNS_12generic_fileEm+0x60) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar25macro_tools_create_layersERNS_16user_interactionERNS_4pileERNS_14header_versionERNS_12slice_layoutEPKS6_PNS_11memory_poolERKNS_8entrepotERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESM_bbbRKNS_8limitintImEENS_11compressionEmSQ_SQ_SM_NS_11crypto_algoERKNS_11secu_stringEjRKSt6vectorISK_SaISK_EES10_bSM_bSM_NS_9hash_algoESQ_RKNS_5labelES14_b+0xd59) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar7archive16op_create_in_subERNS_16user_interactionENS0_9operationERKNS_4pathERKNS_8entrepotEPKNS_9catalogueESC_bRKNS_4maskESF_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESN_bRKNS_11crit_actionEbbbbbbRKNS_8limitintImEEbNS_11compressionEmSU_SU_SF_SN_NS_11crypto_algoERKNS_11secu_stringEjRKSt6vectorISL_SaISL_EES14_SF_SU_bSN_SU_bbbbNS_9cat_inode17comparison_fieldsEbbbSU_SN_SU_SU_bbbSU_SN_NS_9hash_algoESU_SN_SF_bRKSt3setINS_10fsa_familyESt4lessIS19_ESaIS19_EEbbPNS_10statisticsE+0x442) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar7archive12op_create_inERNS_16user_interactionENS0_9operationERKNS_4pathERKNS_8entrepotEPS0_RKNS_4maskESD_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESL_bbbbbbbRKNS_8limitintImEEbNS_11compressionEmSP_SP_SD_SL_NS_11crypto_algoERKNS_11secu_stringEjRKSt6vectorISJ_SaISJ_EESZ_SD_SP_bSL_SP_bbbbNS_9cat_inode17comparison_fieldsEbbSP_SL_SP_SP_bbSP_SL_NS_9hash_algoESP_SL_SD_bRKSt3setINS_10fsa_familyESt4lessIS14_ESaIS14_EEbbPNS_10statisticsE+0xa68) 

         stack dump : 
/usr/lib/x86_64-linux-gnu/libdar64.so.5000(_ZN6libdar7archiveC2ERNS_16user_interactionERKNS_4pathES5_RKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESD_RKNS_22archive_options_createEPNS_10statisticsE+0x735) 

         stack dump : dar(+0x2b9e8)
         stack dump : dar(+0x33594)
         stack dump : dar(+0xe471)
         stack dump : 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7) [0x7f074a709b97]
         stack dump : dar(+0xe59a)
[most outside call]
-----------------------------------

  dar version 2.5.14-bis, Copyright (C) 2002-2052 Denis Corbin
    Long options support       : YES

  Using libdar 5.12.1 built with compilation time options:
    Libz compression (gzip)      : YES
    Libbz2 compression (bzip2)   : YES
    Liblzo2 compression (lzo)    : YES
    Liblzma compression (xz)     : NO     <<< NOTE THIS
    Strong encryption (libgcrypt): YES
    Public key ciphers (gpgme)   : YES
    Extended Attributes support  : YES
    Large files support (> 2GB)  : YES
    ext2fs NODUMP flag support   : YES
    Special allocation scheme    : NO
    Integer size used            : 64 bits
    Thread safe support          : YES
    Furtive read mode support    : YES
    Linux ext2/3/4 FSA support   : YES
    Mac OS X HFS+ FSA support    : NO
    Detected system/CPU endian   : little
    Posix fadvise support        : YES
    Large dir. speed optimi.     : YES
    Timestamp read accuracy      : 1 microsecond
    Timestamp write accuracy     : 1 microsecond
    Restores dates of symlinks   : YES

  compiled the Feb 17 2018 with GNUC version 7.3.0
  dar is part of the Disk ARchive suite (Release 2.5.14-bis)

Command line:

   dar -c ... -A... -@... -s... -zxz:6

When -zgzip:6 is used, it works fine. I'd expect a friendly error
telling compression method is unsupported (from -V) rather than an
exception.

Or is this an issue with the Ubuntu's package? (I don't currently
have access to another system to test it outside of Ubuntu.)

dar isn't multi-threaded by itself, as the documentation explains. This
is reasonable. However, why dar's compression is not? Even certain
encryption algos are multi-threaded in openssl (IIRC AES in CBC mode).

Parallel compression (of the same file/data stream, not different dar
processes/trees) is particularly one feature I am missing from dar.

Example: many *nix system come with gz/xz by default. There are also
less used pigz/pixz variants. On a typical server or desktop/high-end
laptop with 8 cores (4+HT), gz/xz never use more than 12.5% of total
system's power. pigz/pixz use 100%, i.e. all cores. This makes drastic
difference in compression speed.

Is there any reason why dar isn't compiled against such gz/xz variants?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

thanks for your feedback, will try to reproduce it and fix this

Best Regards,
Denis

On 23/08/2018 16:13, mannino wrote:
> I have been trying to compile the RC on Windows 10 x64 under the 
> latest cygwin (2.1). I have followed the recipe in the FAQ and got 
> the required packages installed but I'm still facing multiple 
> problems.
> 
> Configure reports:
> 
> LIBDAR parameters: Zlib compression (gzip)    : YES Libbz2 
> compression (bzip2) : YES Liblzo2 compression (lzo)  : YES Liblxz 
> compression (xz)    : YES Strong encryption support  : YES Public 
> key cipher support  : NO Extended Attributes support: YES Large 
> files support (> 2GB): YES extX FSA / nodump support  : NO HFS+
> FSA support           : YES Integer size used          : 64 Thread
> safe support        : YES Furtive read mode          : YES Large 
> directory optim.     : YES posix fadvise support      : YES 
> microsecond read accuracy  : YES microsecond write accuracy : YES 
> can restore symlink dates  : YES can uses multiple threads  : NO 
> Delta-compression support  : YES Remote repository support  : NO
> 
> DAR SUITE command line programs: Long options available : YES 
> Building examples      : NO Building dar_static    : YES using upx 
> at install   : YES building documentation : YES
> 
> However, linking the binary fails with:
> 
> libtool: link: g++ -static -o dar_static.exe command_line.o 
> config_file.o dar.o dar_suite.o hide_file.o no_comment.o 
> line_tools.o crit_action_cmd_line.o  -lintl 
> ../libdar/.libs/libdar64.a -lpthread -lrsync -lgcrypt -lgpg-error 
> -llzma -llzo2 -lbz2 -lz -ldl 
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/l
d:
>
>
> 
cannot find -lrsync
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/l
d:
>
>
> 
cannot find -lgcrypt
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/l
d:
>
>
> 
cannot find -lgpg-error
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/l
d:
>
>
> 
cannot find -llzma
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/l
d:
>
>
> 
cannot find -llzo2
> collect2: error: ld returned 1 exit status make[3]: *** 
> [Makefile:565: dar_static.exe] Error 1
> 
> By inspecting C:\cygwin64\lib I notice that many files have the 
> .dll.a suffix rather than .a (e.g. libpthread.a exists and ld 
> doesn't complain). All of the above 5 libs have the .dll.a suffix. 
> Copying them to .a files made ld happy.
> 
> However, it then fails with inability to resolve iconv functions:
> 
> libtool: link: g++ -static -o dar_static.exe command_line.o 
> config_file.o dar.o dar_suite.o hide_file.o no_comment.o 
> line_tools.o crit_action_cmd_line.o  -lintl 
> ../libdar/.libs/libdar64.a -lpthread -lrsync -lgcrypt -lgpg-error 
> -llzma -llzo2 -lbz2 -lz -ldl 
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(dcigette
xt.o):
>
>
> 
In function `_nl_find_msg':
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1315:
>
>
> 
undefined reference to `libiconv'
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1315:(.text+0x5ed):
>
>
> 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `libiconv' 
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1183:
>
>
> 
undefined reference to `libiconv_open'
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1183:(.text+0x96f):
>
>
> 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `libiconv_open' 
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1177:
>
>
> 
undefined reference to `libiconv_open'
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/dcigettext.c:1177:(.text+0xaf9):
>
>
> 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `libiconv_open' 
> /usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(relocata
ble.o):
>
>
> 
In function `libintl_set_relocation_prefix':
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/relocatable.c:171:
>
>
> 
undefined reference to `libiconv_set_relocation_prefix'
> /usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/int
l/relocatable.c:171:(.text+0x46):
>
>
> 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
> `libiconv_set_relocation_prefix' collect2: error: ld returned 1 
> exit status make[3]: *** [Makefile:565: dar_static.exe] Error 1 
> make[3]: Leaving directory 
> '/cygdrive/t/dar-2.6.0.RC1/src/dar_suite' make[2]: *** 
> [Makefile:415: install-recursive] Error 1 make[2]: Leaving 
> directory '/cygdrive/t/dar-2.6.0.RC1/src' make[1]: *** 
> [Makefile:459: install-recursive] Error 1 make[1]: Leaving 
> directory '/cygdrive/t/dar-2.6.0.RC1' make: *** [Makefile:761: 
> install-strip] Error 2
> 
> I have installed a bunch of gettext-related packages. It still 
> fails.
> 
> I think the FAQ should be updated - it will take minutes for 
> someone familiar with the build process to list all required 
> packages while saving hours of repeated attempts to build for 
> someone who isn't.
> 
> In any case, how do I build dar on Windows?
> 
> ----------------------------------------------------------------------
- --------
>
>
> 
Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
> _______________________________________________ Dar-discussions 
> mailing list Dar...@li... 
> https://lists.sourceforge.net/lists/listinfo/dar-discussions
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW38LowgxsL0D2LGCAQjddQ//U9kppBhY8VZ0bFq8HARdPPNcATjPoAbQ
PTAe9ho0ZTqRy0iQBYAokNwJOLRY6bev10F9qfuuPjdwlgc03fGIbLaKAk7yNLwa
7KQZHXbftBIY9vqhQSKp4VYubu8gSWhwSHpv1kWixa6DU4RMoFI0r7JErycbGQon
JUX9ll2OyPw/Xb80Q14aIPnBAF1a0hZ4tYouVYd81ThGG0D4FZsll9e5DsWXh3+S
XWrFw/xgx7b/8SnUoJ/8AW5zjVzcGc+rZIM8MtUaWZ+m/IRlKRakZ7ikNAusO+Ef
pZhnUXo7pk7ecEZeYtRega4Guhn8fa7EfcK4m/7zejdwoSWTq2zXeDRQHqiiVDes
DXYpAfdQMQVoFNyUVR82EpK9xxPHV/9RLEoPE0xWU5rAzDQTL4J4i7KyFRfetE06
dAmPapHdpm0Dh7VJWiFfJf37CWFn88w+AAWPrrk/rZyB10uGsNE/84IpbgPCHZno
R04mMob2Zb7RFYaaig48hSQleKqXKd4DCRjoD2CaHCb87lws9hYNXLkc9DCY4+WL
QQ8qgx/Z2McXJyrFL2V+/00zYPl2lz/UeIz6ZYgQHL7vtqpNpxhNJYak4rGQLZ85
emOTZ1Rbc2pn0MTCcmTqMULQ2BhLhWxUmYwIjDZ1eN03hZfEpqNqwDYTToyuMi4B
d2AF4xm7qFA=
=qjM4
-----END PGP SIGNATURE-----

I have been trying to compile the RC on Windows 10 x64 under the latest 
cygwin (2.1). I have followed the recipe in the FAQ and got the required 
packages installed but I'm still facing multiple problems.

Configure reports:

   LIBDAR parameters:
    Zlib compression (gzip)    : YES
    Libbz2 compression (bzip2) : YES
    Liblzo2 compression (lzo)  : YES
    Liblxz compression (xz)    : YES
    Strong encryption support  : YES
    Public key cipher support  : NO
    Extended Attributes support: YES
    Large files support (> 2GB): YES
    extX FSA / nodump support  : NO
    HFS+ FSA support           : YES
    Integer size used          : 64
    Thread safe support        : YES
    Furtive read mode          : YES
    Large directory optim.     : YES
    posix fadvise support      : YES
    microsecond read accuracy  : YES
    microsecond write accuracy : YES
    can restore symlink dates  : YES
    can uses multiple threads  : NO
    Delta-compression support  : YES
    Remote repository support  : NO

   DAR SUITE command line programs:
    Long options available : YES
    Building examples      : NO
    Building dar_static    : YES
    using upx at install   : YES
    building documentation : YES

However, linking the binary fails with:

libtool: link: g++ -static -o dar_static.exe command_line.o 
config_file.o dar.o dar_suite.o hide_file.o no_comment.o line_tools.o 
crit_action_cmd_line.o  -lintl ../libdar/.libs/libdar64.a -lpthread 
-lrsync -lgcrypt -lgpg-error -llzma -llzo2 -lbz2 -lz -ldl
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lrsync
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lgcrypt
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lgpg-error
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -llzma
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -llzo2
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:565: dar_static.exe] Error 1

By inspecting C:\cygwin64\lib I notice that many files have the .dll.a 
suffix rather than .a (e.g. libpthread.a exists and ld doesn't 
complain). All of the above 5 libs have the .dll.a suffix. Copying them 
to .a files made ld happy.

However, it then fails with inability to resolve iconv functions:

libtool: link: g++ -static -o dar_static.exe command_line.o 
config_file.o dar.o dar_suite.o hide_file.o no_comment.o line_tools.o 
crit_action_cmd_line.o  -lintl ../libdar/.libs/libdar64.a -lpthread 
-lrsync -lgcrypt -lgpg-error -llzma -llzo2 -lbz2 -lz -ldl
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(dcigettext.o): 
In function `_nl_find_msg':
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1315: 
undefined reference to `libiconv'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1315:(.text+0x5ed): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1183: 
undefined reference to `libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1183:(.text+0x96f): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1177: 
undefined reference to `libiconv_open'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/dcigettext.c:1177:(.text+0xaf9): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_open'
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../lib/libintl.a(relocatable.o): 
In function `libintl_set_relocation_prefix':
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/relocatable.c:171: 
undefined reference to `libiconv_set_relocation_prefix'
/usr/src/debug/gettext-0.19.8.1-2/gettext-tools/../gettext-runtime/intl/relocatable.c:171:(.text+0x46): 
relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`libiconv_set_relocation_prefix'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:565: dar_static.exe] Error 1
make[3]: Leaving directory '/cygdrive/t/dar-2.6.0.RC1/src/dar_suite'
make[2]: *** [Makefile:415: install-recursive] Error 1
make[2]: Leaving directory '/cygdrive/t/dar-2.6.0.RC1/src'
make[1]: *** [Makefile:459: install-recursive] Error 1
make[1]: Leaving directory '/cygdrive/t/dar-2.6.0.RC1'
make: *** [Makefile:761: install-strip] Error 2

I have installed a bunch of gettext-related packages. It still fails.

I think the FAQ should be updated - it will take minutes for someone 
familiar with the build process to list all required packages while 
saving hours of repeated attempts to build for someone who isn't.

In any case, how do I build dar on Windows?

On 18.08.2018 16:50, Denis Corbin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> just to let you know that pre-release phase has started for release
> 2.6.0.  :-)
>
> http://dar.linux.free.fr/pre-release/
Many thanks for pushing the RC sooner than you have planned. I am
looking forward for using it in production soon.

dar is an exceptional tool. Please keep it up.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

just to let you know that pre-release phase has started for release
2.6.0.  :-)

http://dar.linux.free.fr/pre-release/

Regards,
Denis

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBW3gkKwgxsL0D2LGCAQiDhw//ZrXkk7ZA7tB0B2Lg+MhwAVMyqSwuJtFz
Tou3EzTITDOzsZMBcFOJ9W3GxMAQ2mcMXi5TqUKE2g8e954T0WvkaEBc1qSuafiT
/buHWwuxq1Fgvb3XGF44AB0faHVIJ3B1ks2YjRXIzcM2k71JMWHjsh+Fw3x5zKHM
54DmO/w4GTySpykEDMsrqCSAp/syQjihfD88N1xkC0EshDICdmbmHbWvxhlgFbHV
SUHD1KM2X1zXTdJAtqBCQlyN+dUKB5DI5kCXOR69HZZx/9TS5n0C39WUI/bT8xz1
8yxokHKbKeed5Zn+99BopgpTFnf+4UcWsECw/fj/TEuwTLZAj3VT0qCCnXmrFSNs
j1rzQfyc92LGpUvFZKFEwKAdg8O7xZliyO2NYWE72SBAhpQ2fRGFIpyFKsqpgw3f
YvVIfhF+tNXCXkMfi3q357ZANmeHlJAbBtOi9A+8Pv4a/0CJNE/gQ2YtL3qAiHsp
7btrgbQXuCBOKHahDfuGQXo7zf7zK6v0DYoNkeRYnRk/rFpQyicZnLCYa0P9UARj
wka/GRdKNN7pGu7mB6CIg3Gb+JjEKuz5LBETte91PQxpgzT1WnjjdCRzOraW3CDi
hPfCxtT5yGHraDKjSwxYHEezoBXfw1cz+SHZhJa5MpGgThSLggyIx1AcFUXWwnju
Ej/XhT8SU5I=
=4fez
-----END PGP SIGNATURE-----

On Monday, July 2, 2018 10:16:46 PM CEST Denis Corbin wrote:
> On 02/07/2018 07:40, J. Roeleveld wrote:
> > On Sunday, July 1, 2018 10:21:51 PM CEST Denis Corbin wrote:
> >> On 01/07/2018 16:12, mannino wrote:
> >>> Is there any estimate on when 2.6 will be made available for
> >>> public? I have read it has been stable since last year (?) and
> >>> originally planned for release "near the end of" 2017.
> >> 
> >> yes, the project got some delay due to heavy load at work (I mean
> >> real work, the one I'm paid for) family constraints and some new
> >> features that were more complex than I expected to add properly.
> >> 
> >> I have completed all planned features, the libdar API needed a
> >> global redesign, this is done too. Features have been tested
> >> individually, but there is still a lot of testing to perform
> >> globally and probably some bugs to understand and fix. I also
> >> need to do performance testing due to the change of memory
> >> allocation used.
> > 
> > Denis,
> > 
> > If you have test-scripts that can be fired off against large (Think
> > multiple TBs and thousands of files) datasets, let me know. I got a
> > machine where I can let a few scripts run without impacting
> > production too much. I don't have time to fully test myself, but if
> > the scripts can run unattended and have consistency checks built-in
> > with proper reporting, I can offer my services.
> 
> Thanks a lot, this will be helful in time.
> 
> But, what I will lack the most is the diversity of operating system to
> test dar/libdar on...

All important files are all stored on the server, which runs Linux.
The 2 MS Windows VMs are "backed up" using synchronisation to the backup-
server.

I could spin up a few test-VMs where similar scripts can be run.

--
Joost

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/07/2018 21:16, mannino wrote:
> On 01.07.2018 23:21, Denis Corbin wrote:
>> So to be precise, I concentrate on crypto upgrade, performance
>> and documentation, for I hope a pre-release phase in September,
>> maybe sooner.
> Uh-huh, looks like about half a year longer. Thanks for the
> information.
> 
> Perhaps a donation may speed up the release?

unfortunately not, the problem is not money, nor will, nor motivation
but time, free time... :-/

> 
>> Which feature do you expect to find in 2.6.x?
> Honestly to me dar is about as complete as I need, and the only
> feature I miss badly is --delta. (Deduplication would be also
> welcome, but more as a convenience than a necessity.) This is
> because in most situations files that I want to backup have their
> mode and other attributes changing pretty randomly which renders
> incremental dar backup useless (identical to full).

Yep, this is ready and tested, so you will have in 2.6.0

> 
> For example, a VMware node has its disks split into a multitude of 
> files. Node snapshots create even more files, and each file can
> take many gigabytes. When a node is running, it's constantly
> refreshing modification times on its disk files (among other
> things) even if it doesn't write to them (but even if it does, it
> only changes portions of those files).

I've observed this too :-)

> 
> This means if you do a dar backup before starting a node, start a
> node, stop it and attempt to do an incremental backup - instead of
> a virtually empty second backup you get it about as large as the
> first one which is extremely space-inefficient, not to mention that
> write speed onto the backup medium may be very poor and would not
> be saturated by encryption and compression running altogether,
> leaving room for other optimizations (namely delta calculation).
> 
> Thus the only way to have a realistic setup with dar is to
> radically reduce the amount of data being stored, and this can only
> be achieved with --delta.
> 

Agreed, so I take not of this and do my best to have it released soon

Regards,
Denis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBWzqLRAgxsL0D2LGCAQg+tQ/+KH6FPmtBihYpPjl2jlLuzE5oVztQeMgV
3MJCgXvwEPr4p5XgdAmHl+TVAgnKoqi52cjqxza3WoPANDo35inxoEo1Pd5f0qWq
St/oC6M27kOg1ujlX/gugn41Y3dhz+wZiIOsAxBWsIKspImugu9yab5q83SswS9G
dk+yriXx9jGMls9VYlMhfHDnfshIlj4BQFXoX8Q9f5PiTlSPwntraLUtedb6UD2k
BLuA1bTZ/tdPV4JvjbGmqJkrlYclU+xOr51fVZj2G5sdhSMH/we4l795BYOwHeSO
kz7S2KcIEYfwAd/IkOijPWe97UIWCWOiPK9UL3mZfI+ttNobnFuAafIx5znmTVTC
/VhRtRf4p2UZZyhKZtDp3KfFv2UZ/az60OV0bQe884tRjcb6IFo00rINJAlYEOFb
7rRT2UTJnC1/RRf9Iw8wZLUQHRukiTx45ws628LfYaGjwCg2trkqDUj/j6mHFDH8
gytaVJ7fv86dtqXE/fll+PYBcdns7z09OIpkjSXw+PARCVcCfbHKq1zLluH8AekB
ywvmdaIrspDoeRtbsvc5K9eHfH7ydN9US+LUi6V3HMfXpI9SU0fUXbzbjuXjhQcF
Fy/BfqTOzpUExIqs9udOeXsV6/LSwUvI8jGcAJh6Fc0ilAZuGfdUt4TzcD4yb5RG
DXpiWCbLSVE=
=W7WH
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 02/07/2018 07:40, J. Roeleveld wrote:
> On Sunday, July 1, 2018 10:21:51 PM CEST Denis Corbin wrote:
>> On 01/07/2018 16:12, mannino wrote:
>>> Is there any estimate on when 2.6 will be made available for 
>>> public? I have read it has been stable since last year (?) and 
>>> originally planned for release "near the end of" 2017.
>> 
>> yes, the project got some delay due to heavy load at work (I mean
>> real work, the one I'm paid for) family constraints and some new
>> features that were more complex than I expected to add properly.
>> 
>> I have completed all planned features, the libdar API needed a
>> global redesign, this is done too. Features have been tested
>> individually, but there is still a lot of testing to perform
>> globally and probably some bugs to understand and fix. I also
>> need to do performance testing due to the change of memory
>> allocation used.
> 
> Denis,
> 
> If you have test-scripts that can be fired off against large (Think
> multiple TBs and thousands of files) datasets, let me know. I got a
> machine where I can let a few scripts run without impacting
> production too much. I don't have time to fully test myself, but if
> the scripts can run unattended and have consistency checks built-in
> with proper reporting, I can offer my services.

Thanks a lot, this will be helful in time.

But, what I will lack the most is the diversity of operating system to
test dar/libdar on...

> 
> -- Joost
> 


Regards,
Denis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBWzqILQgxsL0D2LGCAQiiOw//R9JJz7U3J8Nr0YdQNjUvVwp985m2j/ER
6IG+yQGwIHzXhXjuhaiolVBom2xIP4KKzX2bX1ctw/2NpErlbuHL3K2cNS665vQE
6G7PAxHkG94Ani3ALYG+ohqao7+KAuKawu6/8zTpm8+feQ6TzsTM7OZT3Lt+4BsT
uqOI8QmsQkN6I/U/3mbXz36qt44TcTlbwryoEIhQf3mDoc5yZdt+QHdlR34QYWkM
BQWQH/1PweF7OnRHehT05SVraKgOHBxXKgNfaCzzq7USujE8j+0/TBJKC8kB81KP
sYlWX6y1kha4CY4PSCvZprHpiRR1QTbiLvOEYK2vtNvCXjyD9p2v1isKXbQPyfbl
7RnuF867nBu1oh1e06aYbzH1HvNpcW28coQit5clNxN+AbJ60sAsUEZJdP3M1jJB
GKL5V0nXB6JbywcfWbu+eKANB5UXKTplpaeVHsyPbMOE0IUv885siwKT89ahTHP6
ryL+8VYdVDqq9QB3dA7dQyI3Mj8jtGrWRIkac4nAzF6oYgkLqTad33/blM9QArIB
edt+psuNS6yO0jScoGasx/MuGyQOvMGKCPmTjHHoJy/B3sokapdhNmIlREQfPzir
8jmYmfXwizEhoTaZFSLlxJD+vraiEZOws4RSwrwPYBMuzeuqKpjPkQfvrIWbVdGd
jHibc+phH5k=
=cnft
-----END PGP SIGNATURE-----

On Sunday, July 1, 2018 10:21:51 PM CEST Denis Corbin wrote:
> On 01/07/2018 16:12, mannino wrote:
> > Is there any estimate on when 2.6 will be made available for
> > public? I have read it has been stable since last year (?) and
> > originally planned for release "near the end of" 2017.
> 
> yes, the project got some delay due to heavy load at work (I mean real
> work, the one I'm paid for) family constraints and some new features
> that were more complex than I expected to add properly.
> 
> I have completed all planned features, the libdar API needed a global
> redesign, this is done too. Features have been tested individually,
> but there is still a lot of testing to perform globally and probably
> some bugs to understand and fix. I also need to do performance testing
> due to the change of memory allocation used.

Denis,

If you have test-scripts that can be fired off against large (Think multiple 
TBs and thousands of files) datasets, let me know.
I got a machine where I can let a few scripts run without impacting production 
too much.
I don't have time to fully test myself, but if the scripts can run unattended 
and have consistency checks built-in with proper reporting, I can offer my 
services.

--
Joost

On 01.07.2018 23:21, Denis Corbin wrote:
> So to be precise, I concentrate on crypto upgrade, performance and
> documentation, for I hope a pre-release phase in September, maybe
> sooner.
Uh-huh, looks like about half a year longer. Thanks for the information.

Perhaps a donation may speed up the release?

> Which feature do you expect to find in 2.6.x?
Honestly to me dar is about as complete as I need, and the only feature
I miss badly is --delta. (Deduplication would be also welcome, but more
as a convenience than a necessity.) This is because in most situations
files that I want to backup have their mode and other attributes
changing pretty randomly which renders incremental dar backup useless
(identical to full).

For example, a VMware node has its disks split into a multitude of
files. Node snapshots create even more files, and each file can take
many gigabytes. When a node is running, it's constantly refreshing
modification times on its disk files (among other things) even if it
doesn't write to them (but even if it does, it only changes portions of
those files).

This means if you do a dar backup before starting a node, start a node,
stop it and attempt to do an incremental backup - instead of a virtually
empty second backup you get it about as large as the first one which is
extremely space-inefficient, not to mention that write speed onto the
backup medium may be very poor and would not be saturated by encryption
and compression running altogether, leaving room for other optimizations
(namely delta calculation).

Thus the only way to have a realistic setup with dar is to radically
reduce the amount of data being stored, and this can only be achieved
with --delta.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256



On 01/07/2018 16:12, mannino wrote:
> Is there any estimate on when 2.6 will be made available for
> public? I have read it has been stable since last year (?) and
> originally planned for release "near the end of" 2017.

yes, the project got some delay due to heavy load at work (I mean real
work, the one I'm paid for) family constraints and some new features
that were more complex than I expected to add properly.

I have completed all planned features, the libdar API needed a global
redesign, this is done too. Features have been tested individually,
but there is still a lot of testing to perform globally and probably
some bugs to understand and fix. I also need to do performance testing
due to the change of memory allocation used.

I had planned to provide a real C and Python API to libdar in addition
to the native C++ API. The Python binding done by Wesley Legette years
ago has not been maintained while libdar has received many new
features releases after releases... thus I find easier to restart this
from scratch... But I have postponed these API for after release 2.6.0
to gain time.

Last some crypto specific things have to be upgraded too to adapt to
the evolution of technology and means, for example using AES by
default instead of blowfish, increase key sizes, change hashing
algorithms and so on...

So to be precise, I concentrate on crypto upgrade, performance and
documentation, for I hope a pre-release phase in September, maybe
sooner. Don't take it for granted, I work on my spare time... but I
Will do my best to hold this target. The official release would take
place one or two month later depending on the number of persons
participating in the pre-release phase.

> 
> I am currently deploying a backup system which absolutely must use
> the --delta feature of dar. I'd like to know if I should wait for
> 2.6 a bit longer or look for alternative options (I love dar and
> would rather stick to it when possible).

Which feature do you expect to find in 2.6.x?


Thanks for your patience,
Denis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIVAwUBWzk33wgxsL0D2LGCAQhoMRAAg+NgnPFTPDRHNvYMHkK5kg+lRPj9N3dX
BBg3gcE/AHlAZdIQOF3rOobR4EAA/mLK2nedmnhhRLxGstKcFgJUHFduXwqSo3Wv
Yi1NVAmjKNaRYwz7ZiHBck3RASmNaONLiCXjcHm+z5UW8bSwvYipnRZDxH8ZPjxK
8KJjqUA9qOeQcav0BvpY9HTPdWK8uBoIu/68t2gPcu8naOmqDJqoqkYEIXaE+qTb
XH1qLjFkUSQZGwedaYK+s8zmA0EB6AQx19WpordxikRWJvud/trh95AZJ6CRnZWY
XbRYzUWQGP6UsB6kE4cckNPof6BxXzAIMg8aKfRWNGRoukmQNU61hyTzApG6vPZ1
6MU1VpLCNP5ljUbuAqIi292VarpTprAv1Cu7XIaBtF1kXYnhUOe8D+cH0ykPF0v7
5QYZZ0MhxeHfBP/TldOlL7Cj8yRrxgX1GRnxxglmVplg8yF6DNIpaTYaOIrTgSIR
CJCzaTvPAWNwWkOE3A42VZMvAbxCRWXCX7EzjLpQaZ0QxrbD1zoNhOzFshxokdKl
A3W2OErzTWEr7eo0jaQ3E506VIol9uQdKru331EobC9FeXe8pjCGvsE4Svdl6vOS
R3O2vtYe33Jwoq7Y213e+sTXYwclWKek+V+S45Tk7okNXzREvGNTHV3Q9kvHHr2u
GTXHN7+gmLc=
=LXFd
-----END PGP SIGNATURE-----

Is there any estimate on when 2.6 will be made available for public? I
have read it has been stable since last year (?) and originally planned
for release "near the end of" 2017.

I am currently deploying a backup system which absolutely must use the
--delta feature of dar. I'd like to know if I should wait for 2.6 a bit
longer or look for alternative options (I love dar and would rather
stick to it when possible).