Re: [Duplicity-talk] Announ cing Déjà Dup

[Peter Schuller]

> What sort of files should never be backed up?  Like, should my
> frontend try to stop the user from backing up /dev?

I think only recently someone had trouble with /proc. I don't remember
off hand what the deal is with /dev in duplicity's case.

Also, until and unless fixed in duplicity itself, one wants to exclude
the directory used for temporary files (this was discussed here
recently).

> I have some changes in duplicity that would make the life of a
> frontend writer much easier.  How interested are duplicity developers
> in the following changes?

I can't speak for Kenneth or other people, but personally I'm always
in favor of that type of change. That said, even better would be to
libify the whole thing.

> * Progress feedback.  Does duplicity offer any sort of feedback like
> "backing up XXX... 45 of 13530 files"?  Pumping such information to
> stdout or stderr in either text or in some binary format would let my
> frontend give the user much more useful feedback (right now it just
> uses a 'pulsing' progress bar).

Indirectly it tells you which volume it's on if you run at high
verbosity, but that's for humans only. Also, the total number of
volumes is not known until the backup is complete.

Progress in terms of source files would be useful; I'm not aware of a
simple way of adding support for this though, due to the "streaming
tar" internal design.

> * Errors.  Right now duplicity always exits with the value 1 on error.
>  It would help me a lot if there were a separate error code for each
> error.  That way I could notice that, say, duplicity errored out
> because of a source mismatch and offer a dialog with buttons like
> "Ignore" and "Cancel" and rerun duplicity if needed.  Right now, I can
> only throw up a dialog with the error text and there's no way for the
> user to rerun with the right --allow-source-mismatch flag.  I could
> try to parse the stderr output, but that is very error prone.  An exit
> value would be much more useful.

I agree. Error handling in general needs improvement. Any input on the
most useful, from your perspective as a front-end writer, categories
of failures that you wish to distinguish between would presumably be
useful here.

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <address@hidden>'
Key retrieval: Send an E-Mail to address@hidden
E-Mail: address@hidden Web: http://www.scode.org

pgpTDrYe94nmQ.pgp
Description: PGP signature