UCWE on deep check with recent version #1628

Closed
opened 2011-11-30 22:54:54 +00:00 by daira · 29 comments

Reported by kpreid:
I upgraded my tahoe to a recent development version, in the git mirror:

  git://github.com/warner/tahoe-lafs.git
  commit b73aba98de93c4c0b0013f1dd435c64e73e48f4c

Now, my daily deep-check --repair --add-lease on my four aliases on the volunteer grid consistently fails as follows. The first might have a legitimate uncoordinated write, but the last two are not regularly touched by anything but the repair process, and this identical failure has occurred for the past 4 days.

I'd appreciate it if this is fixed before my leases expire. :-)

ERROR: UncoordinatedWriteError()
"[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: "

ERROR: AssertionError()
"[Failure instance: Traceback: <type 'exceptions.AssertionError'>: "
/Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:563:upload
/Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:661:_do_serialized
/Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:298:addCallback
/Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:287:addCallbacks
--- <exception caught here> ---
/Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:545:_runCallbacks
/Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:661:<lambda>
/Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:689:_upload
/Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/publish.py:402:publish

ERROR: UncoordinatedWriteError()
"[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: "

ERROR: UncoordinatedWriteError()
"[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: "

Before these failures, here is a typical example of normal results. (The indentation is added by my script.) I had understood the post-repair unhealthiness to be due to disagreement between the "healthy file" and "repair (successful re-upload)", a to-be-fixed bug.

	done: 3 objects checked
	 pre-repair: 3 healthy, 0 unhealthy
	 0 repairs attempted, 0 successful, 0 failed
	 post-repair: 3 healthy, 0 unhealthy

	 repair successful
	done: 1 objects checked
	 pre-repair: 0 healthy, 1 unhealthy
	 1 repairs attempted, 1 successful, 0 failed
	 post-repair: 0 healthy, 1 unhealthy

	 repair successful
	done: 5 objects checked
	 pre-repair: 4 healthy, 1 unhealthy
	 1 repairs attempted, 1 successful, 0 failed
	 post-repair: 4 healthy, 1 unhealthy

	 repair successful
	done: 5 objects checked
	 pre-repair: 4 healthy, 1 unhealthy
	 1 repairs attempted, 1 successful, 0 failed
	 post-repair: 4 healthy, 1 unhealthy
[Reported by kpreid](https://tahoe-lafs.org/pipermail/tahoe-dev/2011-November/006870.html): I upgraded my tahoe to a recent development version, in the git mirror: ``` git://github.com/warner/tahoe-lafs.git commit b73aba98de93c4c0b0013f1dd435c64e73e48f4c ``` Now, my daily deep-check --repair --add-lease on my four aliases on the volunteer grid consistently fails as follows. The first might have a legitimate uncoordinated write, but the last two are not regularly touched by anything but the repair process, and this identical failure has occurred for the past 4 days. I'd appreciate it if this is fixed before my leases expire. :-) ``` ERROR: UncoordinatedWriteError() "[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: " ERROR: AssertionError() "[Failure instance: Traceback: <type 'exceptions.AssertionError'>: " /Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:563:upload /Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:661:_do_serialized /Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:298:addCallback /Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:287:addCallbacks --- <exception caught here> --- /Volumes/Opp/External/Projects/tahoe/support/lib/python2.6/site-packages/Twisted-11.1.0-py2.6-macosx-10.6-x86_64.egg/twisted/internet/defer.py:545:_runCallbacks /Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:661:<lambda> /Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/filenode.py:689:_upload /Volumes/Opp/External/Projects/tahoe/src/allmydata/mutable/publish.py:402:publish ERROR: UncoordinatedWriteError() "[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: " ERROR: UncoordinatedWriteError() "[Failure instance: Traceback (failure with no frames): <class 'allmydata.mutable.common.UncoordinatedWriteError'>: " ``` Before these failures, here is a typical example of normal results. (The indentation is added by my script.) I had understood the post-repair unhealthiness to be due to disagreement between the "healthy file" and "repair (successful re-upload)", a to-be-fixed bug. ``` done: 3 objects checked pre-repair: 3 healthy, 0 unhealthy 0 repairs attempted, 0 successful, 0 failed post-repair: 3 healthy, 0 unhealthy repair successful done: 1 objects checked pre-repair: 0 healthy, 1 unhealthy 1 repairs attempted, 1 successful, 0 failed post-repair: 0 healthy, 1 unhealthy repair successful done: 5 objects checked pre-repair: 4 healthy, 1 unhealthy 1 repairs attempted, 1 successful, 0 failed post-repair: 4 healthy, 1 unhealthy repair successful done: 5 objects checked pre-repair: 4 healthy, 1 unhealthy 1 repairs attempted, 1 successful, 0 failed post-repair: 4 healthy, 1 unhealthy ```
daira added the
c/code
p/major
t/defect
v/1.9.0
labels 2011-11-30 22:54:54 +00:00
daira added this to the undecided milestone 2011-11-30 22:54:54 +00:00
Author

I had understood the post-repair unhealthiness to be due to disagreement between the "healthy file" and "repair (successful re-upload)", a to-be-fixed bug.

Yes, that sounds like #766.

> I had understood the post-repair unhealthiness to be due to disagreement between the "healthy file" and "repair (successful re-upload)", a to-be-fixed bug. Yes, that sounds like #766.
killyourtv commented 2011-12-01 10:17:26 +00:00
Owner

I had the same problem after upgrading to 1.9, reported in #1583 (though I neglected to add the full traceback).

I had the same problem after upgrading to 1.9, reported in #1583 (though I neglected to add the full traceback).

Thanks for the information, kpreid and killyourtv. Kevin, would you please attempt to reproduce it and see if a foolscap incident report file is generated in ~/.tahoe/logs/incidents/, and then push the "Report A Problem" button as killyourtv did in #1583?

Thanks for the information, kpreid and killyourtv. Kevin, would you please attempt to reproduce it and see if a foolscap incident report file is generated in `~/.tahoe/logs/incidents/`, and then push the "Report A Problem" button as killyourtv did in #1583?

Attachment incident-2011-12-06--13-30-43Z-kt36tjq.flog.bz2 (56514 bytes) added

Repair failure #1 (UncoordinatedWriteError)

**Attachment** incident-2011-12-06--13-30-43Z-kt36tjq.flog.bz2 (56514 bytes) added Repair failure #1 (UncoordinatedWriteError)

Attachment incident-2011-12-06--13-30-54Z-uzuao2q.flog.bz2 (55321 bytes) added

Repair failure 3 (UncoordinatedWriteError)

**Attachment** incident-2011-12-06--13-30-54Z-uzuao2q.flog.bz2 (55321 bytes) added Repair failure 3 (UncoordinatedWriteError)

Attachment incident-2011-12-06--13-31-29Z-oq7v3wi.flog.bz2 (55136 bytes) added

Pushed the "Report an Incident" button

**Attachment** incident-2011-12-06--13-31-29Z-oq7v3wi.flog.bz2 (55136 bytes) added Pushed the "Report an Incident" button

For some reason I cannot upload the second of the four incident files, which contained an AssertionError from mutable/filenode.py:563:upload. I have tried several times, including with a different format and filename, and Trac acts as if it succeeded but doesn't show the file. I have temporarily uploaded it here: http://switchb.org/pri/incident-2011-12-06--13-30-50Z-fhhyszi.flog.bz2

For some reason I cannot upload the second of the four incident files, which contained an [AssertionError](wiki/AssertionError) from `mutable/filenode.py:563:upload`. I have tried several times, including with a different format and filename, and Trac acts as if it succeeded but doesn't show the file. I have *temporarily* uploaded it here: <http://switchb.org/pri/incident-2011-12-06--13-30-50Z-fhhyszi.flog.bz2>
kevan commented 2011-12-13 01:22:29 +00:00
Owner

Hm, it looks like the publisher forgot how to keep track of multiple copies of a single share during the MDMF implementation. So, in your case, it knows about one copy of each of a few shares that each exist on more than one server, then gets surprised when it encounters the other copies when pushing other shares, interprets the shares as evidence of an uncoordinated write, and breaks. Can you test attachment:fix-1628.darcs.patch and let me know if it resolves the issue for you?

Hm, it looks like the publisher forgot how to keep track of multiple copies of a single share during the MDMF implementation. So, in your case, it knows about one copy of each of a few shares that each exist on more than one server, then gets surprised when it encounters the other copies when pushing other shares, interprets the shares as evidence of an uncoordinated write, and breaks. Can you test [attachment:fix-1628.darcs.patch](/tahoe-lafs/trac/attachments/000078ac-b26a-d862-c552-27cdbab7fc5e) and let me know if it resolves the issue for you?
kevan commented 2011-12-13 01:23:13 +00:00
Owner

Attachment fix-1628.darcs.patch (84710 bytes) added

**Attachment** fix-1628.darcs.patch (84710 bytes) added

I'm currently trying not to have to deal with darcs. If you can supply that as a unified diff or against the git mirror I can test it.

I'm currently trying not to have to deal with darcs. If you can supply that as a unified diff or against the git mirror I can test it.
kevan commented 2011-12-13 02:19:28 +00:00
Owner

Attachment fix-1628.diff (18873 bytes) added

darcs-free version of fix-1628.darcs.patch

**Attachment** fix-1628.diff (18873 bytes) added darcs-free version of fix-1628.darcs.patch
kevan commented 2011-12-13 02:23:18 +00:00
Owner

Does attachment:fix-1628.diff work for you? Don't mind the references to a fifth patch; it's not related to this issue.

Does [attachment:fix-1628.diff](/tahoe-lafs/trac/attachments/000078ac-b26a-d862-c552-73526e2718cc) work for you? Don't mind the references to a fifth patch; it's not related to this issue.

fix-1628.diff appears to have eliminated the problem.

fix-1628.diff appears to have eliminated the problem.

Replying to kpreid:

For some reason I cannot upload the second of the four incident files, which contained an AssertionError from mutable/filenode.py:563:upload. I have tried several times, including with a different format and filename, and Trac acts as if it succeeded but doesn't show the file.

That's due to a misconfiguration of this Trac. #1581 My apologies.

Replying to [kpreid](/tahoe-lafs/trac/issues/1628#issuecomment-387879): > For some reason I cannot upload the second of the four incident files, which contained an [AssertionError](wiki/AssertionError) from `mutable/filenode.py:563:upload`. I have tried several times, including with a different format and filename, and Trac acts as if it succeeded but doesn't show the file. That's due to a misconfiguration of this Trac. #1581 My apologies.

So is this a regression in 1.9.0 vs. earlier releases, and could it result in data loss, and should we plan a 1.9.1 release to fix it?

So is this a regression in 1.9.0 vs. earlier releases, and could it result in data loss, and should we plan a 1.9.1 release to fix it?
killyourtv commented 2011-12-13 22:54:46 +00:00
Owner

Replying to kpreid:

fix-1628.diff appears to have eliminated the problem.

I concur, this seems to have solved my problem as well (though I want to do a bit more testing).

I assume that #1583 is probably the same as this bug. I'll close mine since this one has had a bit more activity.

Replying to [kpreid](/tahoe-lafs/trac/issues/1628#issuecomment-387883): > fix-1628.diff appears to have eliminated the problem. I concur, this seems to have solved my problem as well (though I want to do a bit more testing). I assume that #1583 is probably the same as this bug. I'll close mine since this one has had a bit more activity.
Author

From the patch comments:

This tests for two regressions resulting from a design flaw in the 1.9
mutable publisher; specifically, that the publisher doesn't keep track
of more than one server for each share. This can lead to spurious UCWEs,
as seen in ticket #1628. This also means that the publisher will no
longer write shares associated with a new version of a mutable file over
all of the existing shares that it can find, which potentially decreases
the robustness of the new version of the mutable file.

This sounds to me like a regression serious enough to justify a 1.9.1. Although multiple servers holding the same share shouldn't happen if there have been only publish operations with a stable set of servers, it can easily happen if the grid membership is less stable and there have been repairs.

From the patch comments: ``` This tests for two regressions resulting from a design flaw in the 1.9 mutable publisher; specifically, that the publisher doesn't keep track of more than one server for each share. This can lead to spurious UCWEs, as seen in ticket #1628. This also means that the publisher will no longer write shares associated with a new version of a mutable file over all of the existing shares that it can find, which potentially decreases the robustness of the new version of the mutable file. ``` This sounds to me like a regression serious enough to justify a 1.9.1. Although multiple servers holding the same share shouldn't happen if there have been only publish operations with a stable set of servers, it can easily happen if the grid membership is less stable and there have been repairs.
daira modified the milestone from undecided to soon 2011-12-14 00:48:51 +00:00
kevan commented 2011-12-15 03:01:03 +00:00
Owner

I agree with comment:387887. While investigating this issue, I noticed a potential regression in the way we handle #546 situations. I haven't had time to investigate that yet, and probably won't have time to investigate until this weekend. Can we wait on 1.9.1 until I make a ticket for that issue, so we can decide if it belongs in 1.9.1?

I agree with [comment:387887](/tahoe-lafs/trac/issues/1628#issuecomment-387887). While investigating this issue, I noticed a potential regression in the way we handle #546 situations. I haven't had time to investigate that yet, and probably won't have time to investigate until this weekend. Can we wait on 1.9.1 until I make a ticket for that issue, so we can decide if it belongs in 1.9.1?
zooko added
p/critical
and removed
p/major
labels 2011-12-16 16:52:21 +00:00
zooko modified the milestone from soon to 1.9.1 2011-12-16 16:52:21 +00:00
kevan commented 2011-12-27 20:38:48 +00:00
Owner

Attachment fix-1628.darcs.2.patch (86211 bytes) added

**Attachment** fix-1628.darcs.2.patch (86211 bytes) added
kevan commented 2011-12-27 20:40:14 +00:00
Owner

attachment:fix-1628.darcs.2.patch fixes a flaw in my initial patch. I think it's ready for review.

[attachment:fix-1628.darcs.2.patch](/tahoe-lafs/trac/attachments/000078ac-b26a-d862-c552-43dc19e33489) fixes a flaw in my initial patch. I think it's ready for review.

oops, I just reviewed and landed the first patch, in changeset:e29323f68fc5447b. I'll see if I can deduce a delta between the two darcs patches..

oops, I just reviewed and landed the *first* patch, in changeset:e29323f68fc5447b. I'll see if I can deduce a delta between the two darcs patches..
Brian Warner <warner@lothar.com> commented 2011-12-28 05:50:43 +00:00
Owner

In changeset:147670fd89a04bad:

mutable publish: fix not-enough-shares detection. Refs #1628.

This should match the "fix-1628.darcs.2.patch" attachment on that ticket.
In changeset:147670fd89a04bad: ``` mutable publish: fix not-enough-shares detection. Refs #1628. This should match the "fix-1628.darcs.2.patch" attachment on that ticket. ```
Brian Warner <warner@lothar.com> commented 2011-12-28 05:52:05 +00:00
Owner

In changeset:147670fd89a04bad:

mutable publish: fix not-enough-shares detection. Refs #1628.

This should match the "fix-1628.darcs.2.patch" attachment on that ticket.
In changeset:147670fd89a04bad: ``` mutable publish: fix not-enough-shares detection. Refs #1628. This should match the "fix-1628.darcs.2.patch" attachment on that ticket. ```

kevan: can you double-check that I got that delta right? I think the
only part that changed was this bit:

        all_shnums = filter(lambda sh: len(self.writers[sh]) > 0,
                            self.writers.iterkeys())
        if len(all_shnums) < self.required_shares or self.surprised:
            return self._failure()

with which I fully concur. Since empty lists are falsey, you could also
express it like:

all_shnums = set([shnum for shnum in self.writers if self.writers[shnum]])
# or
all_shnums = set([shnum for shnum,writers in self.writers.items() if writers])
# or, relying upon the uniqueness of dict keys:
all_shnums = [shnum for shnum,writers in self.writers.items() if writers]
# or, since we only actually care about the count of unique shnums:
shares = len([shnum for shnum,writers in self.writers.items() if writers])

(also, be aware of the DictOfSets that I use in the immutable code
for tracking the shnum->servers mapping)

Should I leave this ticket open until we get that second test written?

kevan: can you double-check that I got that delta right? I *think* the only part that changed was this bit: ``` all_shnums = filter(lambda sh: len(self.writers[sh]) > 0, self.writers.iterkeys()) if len(all_shnums) < self.required_shares or self.surprised: return self._failure() ``` with which I fully concur. Since empty lists are falsey, you could also express it like: ``` all_shnums = set([shnum for shnum in self.writers if self.writers[shnum]]) # or all_shnums = set([shnum for shnum,writers in self.writers.items() if writers]) # or, relying upon the uniqueness of dict keys: all_shnums = [shnum for shnum,writers in self.writers.items() if writers] # or, since we only actually care about the count of unique shnums: shares = len([shnum for shnum,writers in self.writers.items() if writers]) ``` (also, be aware of the `DictOfSets` that I use in the immutable code for tracking the shnum->servers mapping) Should I leave this ticket open until we get that second test written?
kevan commented 2011-12-28 19:26:39 +00:00
Owner

I altered test_multiply_placed_shares to fail if some of the shares aren't updated to the newest version on an update, so we don't need to wait for another test. I guess the git changelogs are a little stale; sorry for any confusion from that.

You caught the only important change with your delta. I also removed

        self.g.clients[0].DEFAULT_ENCODING_PARAMETERS['n'] = 75

from test_multiply_placed_shares. Placing a lot of shares (so each server holds a few shares) made the test yield an UCWE more reliably, but it still sometimes made it to the multiple version check due to #1641. It didn't seem worthwhile to set a magical encoding parameter if it didn't always work, and the test always failed without the fix in any case, so I took it out. It probably doesn't matter either way, but the test might be a little faster without that line.

Thanks for the review, the suggested alternatives, and for landing the fixes.

I altered `test_multiply_placed_shares` to fail if some of the shares aren't updated to the newest version on an update, so we don't need to wait for another test. I guess the git changelogs are a little stale; sorry for any confusion from that. You caught the only important change with your delta. I also removed ``` self.g.clients[0].DEFAULT_ENCODING_PARAMETERS['n'] = 75 ``` from `test_multiply_placed_shares`. Placing a lot of shares (so each server holds a few shares) made the test yield an UCWE more reliably, but it still sometimes made it to the multiple version check due to #1641. It didn't seem worthwhile to set a magical encoding parameter if it didn't always work, and the test always failed without the fix in any case, so I took it out. It probably doesn't matter either way, but the test might be a little faster without that line. Thanks for the review, the suggested alternatives, and for landing the fixes.

Ok, I applied that change too, in changeset:7989fe21cc1465ac. So I think we can close this one now. Thanks!

Ok, I applied that change too, in changeset:7989fe21cc1465ac. So I think we can close this one now. Thanks!
warner added the
r/fixed
label 2011-12-29 00:00:40 +00:00

Replying to kevan:

I agree with comment:387887. While investigating this issue, I noticed a potential regression in the way we handle #546 situations. I haven't had time to investigate that yet, and probably won't have time to investigate until this weekend. Can we wait on 1.9.1 until I make a ticket for that issue, so we can decide if it belongs in 1.9.1?

Kevan: did you do this investigation? Release Manager Brian [//pipermail/tahoe-dev/2011-December/006901.html said] "a week or two" and the Milestone is currently marked as due on 2012-01-15, so I think we have time.

Replying to [kevan](/tahoe-lafs/trac/issues/1628#issuecomment-387889): > I agree with [comment:387887](/tahoe-lafs/trac/issues/1628#issuecomment-387887). While investigating this issue, I noticed a potential regression in the way we handle #546 situations. I haven't had time to investigate that yet, and probably won't have time to investigate until this weekend. Can we wait on 1.9.1 until I make a ticket for that issue, so we can decide if it belongs in 1.9.1? Kevan: did you do this investigation? Release Manager Brian [//pipermail/tahoe-dev/2011-December/006901.html said] "a week or two" and [the Milestone](/tahoe-lafs/trac/milestone/441) is currently marked as due on 2012-01-15, so I think we have time.
kevan commented 2011-12-31 22:06:27 +00:00
Owner

I did -- the result is ticket #1641.

I did -- the result is ticket #1641.
Owner

Hi all,

I'm a tahoe-lafs novice, but playing with my first shares (4 storage servers, 2 clients on 2 of the storage servers, k=2, H=4, N=5) I succeeded within short time frame to fuckup my shares. I'm not yet fully sure what we did to confuse them, but in the end we had one share of seq2 and 5 shares of seq10. A deep-check --repair alias: always resulted in this:

$ tahoe deep-check --repair -v sound:28C3

'': not healthy

repair successful

'28c3.Pausenmusik.mp3': healthy

done: 2 objects checked

pre-repair: 1 healthy, 1 unhealthy

1 repairs attempted, 1 successful, 0 failed

post-repair: 1 healthy, 1 unhealthy

It was always the mutable files which became unhealty. And no number of repairs could get them fixed.

jg71 sugested to use git head, as some bugs were fixed there. I did as proposed and just found out that git head fixes all the above problems without fuss. Great work guys!

Hi all, I'm a tahoe-lafs novice, but playing with my first shares (4 storage servers, 2 clients on 2 of the storage servers, k=2, H=4, N=5) I succeeded within short time frame to fuckup my shares. I'm not yet fully sure what we did to confuse them, but in the end we had one share of seq2 and 5 shares of seq10. A deep-check --repair alias: always resulted in this: $ tahoe deep-check --repair -v sound:28C3 '<root>': not healthy<br> repair successful<br> '28c3.Pausenmusik.mp3': healthy<br> done: 2 objects checked<br> pre-repair: 1 healthy, 1 unhealthy<br> 1 repairs attempted, 1 successful, 0 failed<br> post-repair: 1 healthy, 1 unhealthy It was always the mutable files which became unhealty. And no number of repairs could get them fixed. jg71 sugested to use git head, as some bugs were fixed there. I did as proposed and just found out that git head fixes all the above problems without fuss. Great work guys!
Sign in to join this conversation.
No labels
c/code
c/code-dirnodes
c/code-encoding
c/code-frontend
c/code-frontend-cli
c/code-frontend-ftp-sftp
c/code-frontend-magic-folder
c/code-frontend-web
c/code-mutable
c/code-network
c/code-nodeadmin
c/code-peerselection
c/code-storage
c/contrib
c/dev-infrastructure
c/docs
c/operational
c/packaging
c/unknown
c/website
kw:2pc
kw:410
kw:9p
kw:ActivePerl
kw:AttributeError
kw:DataUnavailable
kw:DeadReferenceError
kw:DoS
kw:FileZilla
kw:GetLastError
kw:IFinishableConsumer
kw:K
kw:LeastAuthority
kw:Makefile
kw:RIStorageServer
kw:StringIO
kw:UncoordinatedWriteError
kw:about
kw:access
kw:access-control
kw:accessibility
kw:accounting
kw:accounting-crawler
kw:add-only
kw:aes
kw:aesthetics
kw:alias
kw:aliases
kw:aliens
kw:allmydata
kw:amazon
kw:ambient
kw:annotations
kw:anonymity
kw:anonymous
kw:anti-censorship
kw:api_auth_token
kw:appearance
kw:appname
kw:apport
kw:archive
kw:archlinux
kw:argparse
kw:arm
kw:assertion
kw:attachment
kw:auth
kw:authentication
kw:automation
kw:avahi
kw:availability
kw:aws
kw:azure
kw:backend
kw:backoff
kw:backup
kw:backupdb
kw:backward-compatibility
kw:bandwidth
kw:basedir
kw:bayes
kw:bbfreeze
kw:beta
kw:binaries
kw:binutils
kw:bitcoin
kw:bitrot
kw:blacklist
kw:blocker
kw:blocks-cloud-deployment
kw:blocks-cloud-merge
kw:blocks-magic-folder-merge
kw:blocks-merge
kw:blocks-raic
kw:blocks-release
kw:blog
kw:bom
kw:bonjour
kw:branch
kw:branding
kw:breadcrumbs
kw:brians-opinion-needed
kw:browser
kw:bsd
kw:build
kw:build-helpers
kw:buildbot
kw:builders
kw:buildslave
kw:buildslaves
kw:cache
kw:cap
kw:capleak
kw:captcha
kw:cast
kw:centos
kw:cffi
kw:chacha
kw:charset
kw:check
kw:checker
kw:chroot
kw:ci
kw:clean
kw:cleanup
kw:cli
kw:cloud
kw:cloud-backend
kw:cmdline
kw:code
kw:code-checks
kw:coding-standards
kw:coding-tools
kw:coding_tools
kw:collection
kw:compatibility
kw:completion
kw:compression
kw:confidentiality
kw:config
kw:configuration
kw:configuration.txt
kw:conflict
kw:connection
kw:connectivity
kw:consistency
kw:content
kw:control
kw:control.furl
kw:convergence
kw:coordination
kw:copyright
kw:corruption
kw:cors
kw:cost
kw:coverage
kw:coveralls
kw:coveralls.io
kw:cpu-watcher
kw:cpyext
kw:crash
kw:crawler
kw:crawlers
kw:create-container
kw:cruft
kw:crypto
kw:cryptography
kw:cryptography-lib
kw:cryptopp
kw:csp
kw:curl
kw:cutoff-date
kw:cycle
kw:cygwin
kw:d3
kw:daemon
kw:darcs
kw:darcsver
kw:database
kw:dataloss
kw:db
kw:dead-code
kw:deb
kw:debian
kw:debug
kw:deep-check
kw:defaults
kw:deferred
kw:delete
kw:deletion
kw:denial-of-service
kw:dependency
kw:deployment
kw:deprecation
kw:desert-island
kw:desert-island-build
kw:design
kw:design-review-needed
kw:detection
kw:dev-infrastructure
kw:devpay
kw:directory
kw:directory-page
kw:dirnode
kw:dirnodes
kw:disconnect
kw:discovery
kw:disk
kw:disk-backend
kw:distribute
kw:distutils
kw:dns
kw:do_http
kw:doc-needed
kw:docker
kw:docs
kw:docs-needed
kw:dokan
kw:dos
kw:download
kw:downloader
kw:dragonfly
kw:drop-upload
kw:duplicity
kw:dusty
kw:earth-dragon
kw:easy
kw:ec2
kw:ecdsa
kw:ed25519
kw:egg-needed
kw:eggs
kw:eliot
kw:email
kw:empty
kw:encoding
kw:endpoint
kw:enterprise
kw:enum34
kw:environment
kw:erasure
kw:erasure-coding
kw:error
kw:escaping
kw:etag
kw:etch
kw:evangelism
kw:eventual
kw:example
kw:excess-authority
kw:exec
kw:exocet
kw:expiration
kw:extensibility
kw:extension
kw:failure
kw:fedora
kw:ffp
kw:fhs
kw:figleaf
kw:file
kw:file-descriptor
kw:filename
kw:filesystem
kw:fileutil
kw:fips
kw:firewall
kw:first
kw:floatingpoint
kw:flog
kw:foolscap
kw:forward-compatibility
kw:forward-secrecy
kw:forwarding
kw:free
kw:freebsd
kw:frontend
kw:fsevents
kw:ftp
kw:ftpd
kw:full
kw:furl
kw:fuse
kw:garbage
kw:garbage-collection
kw:gateway
kw:gatherer
kw:gc
kw:gcc
kw:gentoo
kw:get
kw:git
kw:git-annex
kw:github
kw:glacier
kw:globalcaps
kw:glossary
kw:google-cloud-storage
kw:google-drive-backend
kw:gossip
kw:governance
kw:grid
kw:grid-manager
kw:gridid
kw:gridsync
kw:grsec
kw:gsoc
kw:gvfs
kw:hackfest
kw:hacktahoe
kw:hang
kw:hardlink
kw:heartbleed
kw:heisenbug
kw:help
kw:helper
kw:hint
kw:hooks
kw:how
kw:how-to
kw:howto
kw:hp
kw:hp-cloud
kw:html
kw:http
kw:https
kw:i18n
kw:i2p
kw:i2p-collab
kw:illustration
kw:image
kw:immutable
kw:impressions
kw:incentives
kw:incident
kw:init
kw:inlineCallbacks
kw:inotify
kw:install
kw:installer
kw:integration
kw:integration-test
kw:integrity
kw:interactive
kw:interface
kw:interfaces
kw:interoperability
kw:interstellar-exploration
kw:introducer
kw:introduction
kw:iphone
kw:ipkg
kw:iputil
kw:ipv6
kw:irc
kw:jail
kw:javascript
kw:joke
kw:jquery
kw:json
kw:jsui
kw:junk
kw:key-value-store
kw:kfreebsd
kw:known-issue
kw:konqueror
kw:kpreid
kw:kvm
kw:l10n
kw:lae
kw:large
kw:latency
kw:leak
kw:leasedb
kw:leases
kw:libgmp
kw:license
kw:licenss
kw:linecount
kw:link
kw:linux
kw:lit
kw:localhost
kw:location
kw:locking
kw:logging
kw:logo
kw:loopback
kw:lucid
kw:mac
kw:macintosh
kw:magic-folder
kw:manhole
kw:manifest
kw:manual-test-needed
kw:map
kw:mapupdate
kw:max_space
kw:mdmf
kw:memcheck
kw:memory
kw:memory-leak
kw:mesh
kw:metadata
kw:meter
kw:migration
kw:mime
kw:mingw
kw:minimal
kw:misc
kw:miscapture
kw:mlp
kw:mock
kw:more-info-needed
kw:mountain-lion
kw:move
kw:multi-users
kw:multiple
kw:multiuser-gateway
kw:munin
kw:music
kw:mutability
kw:mutable
kw:mystery
kw:names
kw:naming
kw:nas
kw:navigation
kw:needs-review
kw:needs-spawn
kw:netbsd
kw:network
kw:nevow
kw:new-user
kw:newcaps
kw:news
kw:news-done
kw:news-needed
kw:newsletter
kw:newurls
kw:nfc
kw:nginx
kw:nixos
kw:no-clobber
kw:node
kw:node-url
kw:notification
kw:notifyOnDisconnect
kw:nsa310
kw:nsa320
kw:nsa325
kw:numpy
kw:objects
kw:old
kw:openbsd
kw:openitp-packaging
kw:openssl
kw:openstack
kw:opensuse
kw:operation-helpers
kw:operational
kw:operations
kw:ophandle
kw:ophandles
kw:ops
kw:optimization
kw:optional
kw:options
kw:organization
kw:os
kw:os.abort
kw:ostrom
kw:osx
kw:osxfuse
kw:otf-magic-folder-objective1
kw:otf-magic-folder-objective2
kw:otf-magic-folder-objective3
kw:otf-magic-folder-objective4
kw:otf-magic-folder-objective5
kw:otf-magic-folder-objective6
kw:p2p
kw:packaging
kw:partial
kw:password
kw:path
kw:paths
kw:pause
kw:peer-selection
kw:performance
kw:permalink
kw:permissions
kw:persistence
kw:phone
kw:pickle
kw:pip
kw:pipermail
kw:pkg_resources
kw:placement
kw:planning
kw:policy
kw:port
kw:portability
kw:portal
kw:posthook
kw:pratchett
kw:preformance
kw:preservation
kw:privacy
kw:process
kw:profile
kw:profiling
kw:progress
kw:proxy
kw:publish
kw:pyOpenSSL
kw:pyasn1
kw:pycparser
kw:pycrypto
kw:pycrypto-lib
kw:pycryptopp
kw:pyfilesystem
kw:pyflakes
kw:pylint
kw:pypi
kw:pypy
kw:pysqlite
kw:python
kw:python3
kw:pythonpath
kw:pyutil
kw:pywin32
kw:quickstart
kw:quiet
kw:quotas
kw:quoting
kw:raic
kw:rainhill
kw:random
kw:random-access
kw:range
kw:raspberry-pi
kw:reactor
kw:readonly
kw:rebalancing
kw:recovery
kw:recursive
kw:redhat
kw:redirect
kw:redressing
kw:refactor
kw:referer
kw:referrer
kw:regression
kw:rekey
kw:relay
kw:release
kw:release-blocker
kw:reliability
kw:relnotes
kw:remote
kw:removable
kw:removable-disk
kw:rename
kw:renew
kw:repair
kw:replace
kw:report
kw:repository
kw:research
kw:reserved_space
kw:response-needed
kw:response-time
kw:restore
kw:retrieve
kw:retry
kw:review
kw:review-needed
kw:reviewed
kw:revocation
kw:roadmap
kw:rollback
kw:rpm
kw:rsa
kw:rss
kw:rst
kw:rsync
kw:rusty
kw:s3
kw:s3-backend
kw:s3-frontend
kw:s4
kw:same-origin
kw:sandbox
kw:scalability
kw:scaling
kw:scheduling
kw:schema
kw:scheme
kw:scp
kw:scripts
kw:sdist
kw:sdmf
kw:security
kw:self-contained
kw:server
kw:servermap
kw:servers-of-happiness
kw:service
kw:setup
kw:setup.py
kw:setup_requires
kw:setuptools
kw:setuptools_darcs
kw:sftp
kw:shared
kw:shareset
kw:shell
kw:signals
kw:simultaneous
kw:six
kw:size
kw:slackware
kw:slashes
kw:smb
kw:sneakernet
kw:snowleopard
kw:socket
kw:solaris
kw:space
kw:space-efficiency
kw:spam
kw:spec
kw:speed
kw:sqlite
kw:ssh
kw:ssh-keygen
kw:sshfs
kw:ssl
kw:stability
kw:standards
kw:start
kw:startup
kw:static
kw:static-analysis
kw:statistics
kw:stats
kw:stats_gatherer
kw:status
kw:stdeb
kw:storage
kw:streaming
kw:strports
kw:style
kw:stylesheet
kw:subprocess
kw:sumo
kw:survey
kw:svg
kw:symlink
kw:synchronous
kw:tac
kw:tahoe-*
kw:tahoe-add-alias
kw:tahoe-admin
kw:tahoe-archive
kw:tahoe-backup
kw:tahoe-check
kw:tahoe-cp
kw:tahoe-create-alias
kw:tahoe-create-introducer
kw:tahoe-debug
kw:tahoe-deep-check
kw:tahoe-deepcheck
kw:tahoe-lafs-trac-stream
kw:tahoe-list-aliases
kw:tahoe-ls
kw:tahoe-magic-folder
kw:tahoe-manifest
kw:tahoe-mkdir
kw:tahoe-mount
kw:tahoe-mv
kw:tahoe-put
kw:tahoe-restart
kw:tahoe-rm
kw:tahoe-run
kw:tahoe-start
kw:tahoe-stats
kw:tahoe-unlink
kw:tahoe-webopen
kw:tahoe.css
kw:tahoe_files
kw:tahoewapi
kw:tarball
kw:tarballs
kw:tempfile
kw:templates
kw:terminology
kw:test
kw:test-and-set
kw:test-from-egg
kw:test-needed
kw:testgrid
kw:testing
kw:tests
kw:throttling
kw:ticket999-s3-backend
kw:tiddly
kw:time
kw:timeout
kw:timing
kw:to
kw:to-be-closed-on-2011-08-01
kw:tor
kw:tor-protocol
kw:torsocks
kw:tox
kw:trac
kw:transparency
kw:travis
kw:travis-ci
kw:trial
kw:trickle
kw:trivial
kw:truckee
kw:tub
kw:tub.location
kw:twine
kw:twistd
kw:twistd.log
kw:twisted
kw:twisted-14
kw:twisted-trial
kw:twitter
kw:twn
kw:txaws
kw:type
kw:typeerror
kw:ubuntu
kw:ucwe
kw:ueb
kw:ui
kw:unclean
kw:uncoordinated-writes
kw:undeletable
kw:unfinished-business
kw:unhandled-error
kw:unhappy
kw:unicode
kw:unit
kw:unix
kw:unlink
kw:update
kw:upgrade
kw:upload
kw:upload-helper
kw:uri
kw:url
kw:usability
kw:use-case
kw:utf-8
kw:util
kw:uwsgi
kw:ux
kw:validation
kw:variables
kw:vdrive
kw:verify
kw:verlib
kw:version
kw:versioning
kw:versions
kw:video
kw:virtualbox
kw:virtualenv
kw:vista
kw:visualization
kw:visualizer
kw:vm
kw:volunteergrid2
kw:volunteers
kw:vpn
kw:wapi
kw:warners-opinion-needed
kw:warning
kw:weapi
kw:web
kw:web.port
kw:webapi
kw:webdav
kw:webdrive
kw:webport
kw:websec
kw:website
kw:websocket
kw:welcome
kw:welcome-page
kw:welcomepage
kw:wiki
kw:win32
kw:win64
kw:windows
kw:windows-related
kw:winscp
kw:workaround
kw:world-domination
kw:wrapper
kw:write-enabler
kw:wui
kw:x86
kw:x86-64
kw:xhtml
kw:xml
kw:xss
kw:zbase32
kw:zetuptoolz
kw:zfec
kw:zookos-opinion-needed
kw:zope
kw:zope.interface
p/blocker
p/critical
p/major
p/minor
p/normal
p/supercritical
p/trivial
r/cannot reproduce
r/duplicate
r/fixed
r/invalid
r/somebody else's problem
r/was already fixed
r/wontfix
r/worksforme
t/defect
t/enhancement
t/task
v/0.2.0
v/0.3.0
v/0.4.0
v/0.5.0
v/0.5.1
v/0.6.0
v/0.6.1
v/0.7.0
v/0.8.0
v/0.9.0
v/1.0.0
v/1.1.0
v/1.10.0
v/1.10.1
v/1.10.2
v/1.10a2
v/1.11.0
v/1.12.0
v/1.12.1
v/1.13.0
v/1.14.0
v/1.15.0
v/1.15.1
v/1.2.0
v/1.3.0
v/1.4.1
v/1.5.0
v/1.6.0
v/1.6.1
v/1.7.0
v/1.7.1
v/1.7β
v/1.8.0
v/1.8.1
v/1.8.2
v/1.8.3
v/1.8β
v/1.9.0
v/1.9.0-s3branch
v/1.9.0a1
v/1.9.0a2
v/1.9.0b1
v/1.9.1
v/1.9.2
v/1.9.2a1
v/cloud-branch
v/unknown
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac#1628
No description provided.