do i understand correctly? we currently have no such functionality, we would
have to introduce it?
e.g.
- catch the error set a globals.runtime_error var
- on exit react on that var
something like that? ..ede
On 06.02.2014 23:44, Michael Terry wrote:
Wherever we currently log a warning due
Yeah, I think so. Most of our warnings we deal with immediately.
On 7 February 2014 04:53, edgar.sol...@web.de wrote:
do i understand correctly? we currently have no such functionality, we
would have to introduce it?
e.g.
- catch the error set a globals.runtime_error var
- on exit react
Mike,
if you could give me some pointers i might be able to spare some time soonish.
..ede
On 05.02.2014 04:03, Michael Terry wrote:
I can implement a warning at the end of any run that includes a skipped
restored file, sure. But I'm not sure about timeframe.
On 2 February 2014 09:23,
I can implement a warning at the end of any run that includes a skipped
restored file, sure. But I'm not sure about timeframe.
On 2 February 2014 09:23, edgar.sol...@web.de wrote:
Mike,
sounds like a fair compromise. as you are familiar with the issue, would
you mind implementing it like
Ken,
could you give your take on the below?
i still feel duplicity should exit with an error code after the restore and
mention the files it had problems with in the end. a warning i the middle might
be easily overlooked by the user.
..ede
On 23.01.2014 20:57, edgar.sol...@web.de wrote:
I agree. We try to exit with an error code, but I know we don't keep track
of errors for later reporting. Perhaps just a message that says to examine
the log would suffice for now?
On Fri, Jan 31, 2014 at 7:12 AM, edgar.sol...@web.de wrote:
Ken,
could you give your take on the below?
i
Is there an ETA for 0.6.23? I'd like to see that data loss fix in the wild.
(Ubuntu has it patched in as an update, so no pressure from my side really,
but I still see the occasional question or bug filed about it. The sooner
we get the fix out the better.)
-mt
https://bugs.launchpad.net/duplicity/+bug/1252484
On 23 January 2014 11:51, edgar.sol...@web.de wrote:
On 23.01.2014 17:46, Michael Terry wrote:
Is there an ETA for 0.6.23? I'd like to see that data loss fix in the
wild.
(Ubuntu has it patched in as an update, so no pressure from my
is this possibly related to these new issues people showed up with on the list
as well?
1. https://answers.launchpad.net/duplicity/+question/242530
2. https://bugs.launchpad.net/duplicity/+bug/1271927
thx.. ede
On 23.01.2014 18:09, Michael Terry wrote:
Yes. It is the root cause to both those issues (I've marked as dups).
Anything that looks like:
assert len( patch_seq ) == 1, len( patch_seq )
or
assert first.difftype != diff, patch_seq
or
librsync error 103 while in patch cycle
is fixed by this bug.
On 23 January 2014 12:21,
Just went through and found a few more dups. That should be all of them.
I also tried to explain a bit more about the three symptoms and what a user
can do about it in the master bug.
On 23 January 2014 12:33, Michael Terry m...@mterry.name wrote:
(Note that in explaining this to affected
/me hugs Kenneth
On 23 January 2014 13:24, Kenneth Loafman kenn...@loafman.com wrote:
I'll work on getting the release out this afternoon, possibly tomorrow
morning.
On Thu, Jan 23, 2014 at 12:08 PM, Michael Terry m...@mterry.name wrote:
Just went through and found a few more dups.
On 23.01.2014 19:34, Michael Terry wrote:
There is a separate but related patch in 0.6.23 that makes the bug less
severe by letting the user restore the rest of the files that aren't affected
(rather than aborting restore entirely):
Interesting thought. We do issue a log message... And Deja Dup does
collect those and warn user at end. I hadn't thought of duplicity doing
that collating itself.
I don't know how I feel about an error exit code. I'm not sold, but I
don't feel strongly. Most error returns are currently for
14 matches
Mail list logo
