Custom Query (2551 matches)

I found this new ticket in the spam bucket. I did not write the following:

Hi there, I've looked around but haven't found any recent information (only a ticket from 5 years ago which was not resolved) about this: Can anyone please tell me whether Tahoe-LAFS "plays nice" with Apple's Time Machine, and any special instructions to consider when wanting to set up Tahoe-LAFS for Time Machine backups? Thank you so much in advance! Best, Frederic

When I upload a file into a directory, such as this one: ​http://pubgrid.tahoe-lafs.org/uri/URI:DIR2-RO:ixqhc4kdbjxc7o65xjnveoewym:5x6lwoxghrd5rxhwunzavft2qygfkt27oj3fbxlq4c6p45z5uneq/ , which the timestamps show got linked into this directory at 2010-06-12_03:45:30.369968, the upload of the immutable file doesn't appear on the Recent Uploads and Downloads page:

21:45:38 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	314B	100.0%	Finished
21:45:38 11-Jun-2010	mapupdate MODE_READ	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:31 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	314B	100.0%	Finished
21:45:31 11-Jun-2010	mapupdate MODE_READ	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:30 11-Jun-2010	publish	up4mutkj52kcm2l7c7nvg5j2ua	No	314B	100.0%	Finished
21:45:30 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	624B	100.0%	Finished
21:45:30 11-Jun-2010	mapupdate MODE_WRITE	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:30 11-Jun-2010	publish	up4mutkj52kcm2l7c7nvg5j2ua	No	624B	100.0%	Finished
21:45:30 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	310B	100.0%	Finished
21:45:30 11-Jun-2010	mapupdate MODE_WRITE	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:30 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	310B	100.0%	Finished
21:45:29 11-Jun-2010	mapupdate MODE_READ	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:24 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	310B	100.0%	Finished
21:45:24 11-Jun-2010	mapupdate MODE_READ	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:24 11-Jun-2010	publish	up4mutkj52kcm2l7c7nvg5j2ua	No	310B	100.0%	Finished
21:45:23 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	620B	100.0%	Finished
21:45:23 11-Jun-2010	mapupdate MODE_WRITE	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:45:14 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	620B	100.0%	Finished
21:45:13 11-Jun-2010	mapupdate MODE_READ	up4mutkj52kcm2l7c7nvg5j2ua	No	-NA-	100.0%	Finished
21:32:56 11-Jun-2010	retrieve	up4mutkj52kcm2l7c7nvg5j2ua	No	620B	100.0%	Finished

Argh! These timestamps are in different timezones and neither of them have explicit timezone indicators. Grumble. Also they are of different and non-standard formatting. I just created #1077 (consistent timestamp format and timezone).

Anyway, making some educated guesses about what these timestamps mean, the upload that I completed at around 2010-06-12 03:45:30Z should have appeared in the list as "11-Jun-2010 21:45:30".

It seems like immutable file uploads into a directory never appear on Recent Uploads/Downloads, but immutable file downloads and unlinked immutable file uploads do.

For example in this run:

​http://tahoe-lafs.org/buildbot/builders/hardy-amd64/builds/687/steps/test/logs/stdio

[ERROR]: allmydata.test.test_hung_server.HungServerDownloadTest.test_2_good_8_broken_copied_share

Traceback (most recent call last):
Failure: allmydata.interfaces.NotEnoughSharesError: ran out of shares: complete=sh0,sh2 pending= overdue= unused= need 3. Last failure: None

The download should have succeeded because server 0 should have shares 0 and 2 and server 1 should have share 1.

trunk/src/allmydata/test/test_hung_server.py@4661#L197

This test failure is nondeterministic. The first step is probably to understand why that is and make it fail every time.