Re: [Duplicity-talk] On replacing tar, why not dar ?

[Zach Adams]

I'm totally in support of a rewrite with dar, there's already a feature request for librsync support: http://sourceforge.net/p/dar/feature-requests/122

If libdar uses librsync and we can store the checksums locally (in addition to the catalog, isolation is listed on the dar features page) I think most of what's left will be interface and backends.

As a side note I've been wanting to do a rewrite if I ever had the time simply because starting a very large backup on an existing chain can be very slow, and I have to wait several minutes to type in my password (which won't be an issue once I use a gpg key directly, but still). It'd also be nice to add threaded compression and encryption.

This could also be a chance to make duplicity cross platform.

Just my 2 cents,

Zach

On Tue, Sep 8, 2015 at 10:54 AM, Kenneth Loafman <address@hidden> wrote:

Except for rsync processing, dar does a lot of what we need: compression, encryption, hard links, split files, etc., plus it's fast.  The backend processing could be done after the .dar file creation, so it looks like rsync processing is the only addition to be made.  Granted, handling the signature files would be a PITA, but that could be done by dar as well.  We would only need two file types, dar and sig.

This would do away with most of duplicity's guts and make libdar the central player in duplicity.

This does not sound like a bad idea to me.  Someone else weigh in please.

...Ken

On Mon, Sep 7, 2015 at 10:00 AM, Kenneth Loafman <address@hidden> wrote:

Don't really need to reimplement, just make sure that the python bindings are sufficient to access libdar fully.  I think that driving dar from duplicity would be nearly a rewrite since I see so much that dar does would replace much of duplicity's functionality.  It might even be easier to start with libdar and add the librsync functionality to it, wrapping all that with multiple backends.  Just a wild thought, but it would give us a solid basis on which to add.

A new structure like dar would solve a lot of the problems we currently have, including split signature files, better manifest handling, etc.

Just a thought, but sometimes a complete rewrite solves a lot of problems.

On Wed, Sep 2, 2015 at 9:30 PM, Meta Schima <address@hidden> wrote:

People have made some python bindings to dar, but re-implementing dar in python is probably not feasible.

> -----Original Message-----
> From: address@hidden
> Sent: Mon, 31 Aug 2015 11:35:12 +0200
> To: address@hidden
> Subject: Re: [Duplicity-talk] On replacing tar, why not dar ?
>
> On 31.08.2015 02:50, Meta Schima wrote:
>> Hello,
>>
>>     In regards to:
>>
>> http://duplicity.nongnu.org/new_format.html
>>
>>     Why not use the dar archive ? It was specifically designed to
>> replace tar, and adds all the features that you want:
>>
>> https://en.wikipedia.org/wiki/Dar_%28disk_archiver%29
>> http://dar.linux.free.fr/
>>
>>     It has also been in development for 10 years so is mature.
>>
>>     Just a suggestion.
>>
>
> tar is available as plain python module. are you aware of a python dar
> implementation?
>
> ..ede/duply.net
>
> _______________________________________________
> Duplicity-talk mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/duplicity-talk

____________________________________________________________
FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk

_______________________________________________
Duplicity-talk mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/duplicity-talk