Peter Secor [Sat, 17 May 2008 01:12:57 +0000 (18:12 -0700)]
windows installer - changed to update for Mikes recent changes to add AllmydataManager which uses a named pipe to avoid some permissions issues on Vista and fixes some netowkr problems
Peter Secor [Sat, 17 May 2008 01:04:05 +0000 (18:04 -0700)]
native client - Mikes changes to have a manager to start/stop services with a named pipe, limit the size of the logfile to 5mb, install the loopback adapter, still need to make changes to the installer to automatically start them up
Brian Warner [Thu, 8 May 2008 18:37:30 +0000 (11:37 -0700)]
run a stats provider even if there's no gatherer, since the HTTP /statistics page is then useful. Only run the once-per-second load-monitor if there is a gatherer configured
robk-tahoe [Wed, 7 May 2008 23:42:20 +0000 (16:42 -0700)]
tahoefuse: fix typo which could cause data corruption
a typo in the 'flags2mode' code would wind up passing the O_APPEND
flag into the os open() call, which would cause the file to be opened
in 'strict append' mode, i.e. all writes extend the file, regardless of
calls to seek.
this causes a problem for tahoefuse in that the seek() calls made to
filehandles open through fuse would be ignored when write()s occurred.
this was evidenced by corruption seen when using rsync. it turns out
that rsync actually makes overlapping writes in some cases, i.e. even
when writing a new fresh file out, it still doesn't write a simple
contiguous span of data, but will make writes overlapping data already
written. this is probably related to the way it manages data blocks
internally for rolling checksums etc. at any rate, this bug would
thus cause rsync in those cases to write a chunk of duplicate data
into the file - leading to tahoe securely and reliably storing the
wrong data.
fixing this, so that non-append file opens do not pass O_APPEND seems
to eliminate this problem.
robk-tahoe [Wed, 7 May 2008 23:40:09 +0000 (16:40 -0700)]
tahoefuse: return bogus but useful data to statfs call
previously tahoefuse returned the fs stat for the filesystem the fuse plugin
was running upon (e.g. '/'). this works ok until you need to copy more to
tahoe than the local machine has free disk space, at which point Finder will
refuse to copy 'too much' data.
this changes it so that tahoe always reports 2TiB used of an 8TiB filesystem
this is entirely bogus, but allows copies of up to 2TiB to be initiated.
setup: bundle pycryptopp-0.5.1.tar
pycryptopp-0.3.0 incorrectly crypts AES (depending on compiler and version of Crypto++ used)
Very soon now we're going to set up an "ext" repository to hold all tarballs and no longer check them into our trunk source tree.
setup: don't catch ImportError when importing _auto_deps in allmydata/__init__.py
Nowadays pkg_resources is a runtime requirement, and if there is something screwed up in the installation, we want an explicit ImportError exception as early as possible.
wui: reorganize the welcome.xhtml page
Jake Edge tried Tahoe out and didn't notice the /status page. Hopefully with this new organization people like he will see that link more easily. This also addresses drewp's suggestion that the controls appear above the list of servers instead of below. (I think that was his suggestion.) I also reordered the controls.
this adds munin graphs to present data already published by nodes to
the stats_gatherer, namely mutable files published/retrieved, and
immutable files uploaded, and the bytes thereof
Brian Warner [Wed, 23 Apr 2008 21:52:34 +0000 (14:52 -0700)]
client: don't start the IntroducerClient until the Tub is ready, otherwise we will sometimes connect to the introducer (or other clients) before we've done Tub.setLocation, which loses some information on the introducer status page
Brian Warner [Tue, 22 Apr 2008 00:27:50 +0000 (17:27 -0700)]
mutable read: enable the cache (written during mapupdate, read during retrieve). This speeds up small-file reads by about 30% over a link with an average 25ms RTT
setup: test depends on build, which means it invokes setup.py every time, which is slower but does "the right thing" more often
There is a new target "quicktest" which depends on the .built and .checked-deps files. test-figleaf also depends on the build target now.
Peter Secor [Tue, 22 Apr 2008 00:38:04 +0000 (17:38 -0700)]
windows installer - removing uninstall tests, trying to get to a clean build that works as it's not clear that this latest build can update the virtual drive properly
Peter Secor [Mon, 21 Apr 2008 23:18:29 +0000 (16:18 -0700)]
windows installer - added line to quit the system tray executable which automatically stops the SMB service, removed lnow redundant line to stop SMB service
key_generator: make default key size be a constructor argument instead of a class variable, pass default key size of 522 (the smallest that we can do) in unit tests to make them faster
setup: don't try __import__(name) in _auto_deps.py
This happens to work, because all of our "distribution" (i.e. distributable packaged Python code) names to coincide with all of their "package" (i.e. a directory with a __init__.py in it, which is "import"-able) names, except, I think for Twisted on Brian's debian sid system.
But there's no reason why it should always work, and the only reason for that __import__() was to give us an explicit error message indicating missing requirements in the case that pkg_resources isn't importable or that the requirements don't have correct .egg-info metadata. So, by removing this stanza we may allow certain places to get a more ad-hoc failure message, i.e. an ImportError from somewhere, instead of an ImportError from _auto_deps.py, but that's okay.
Note that dependencies which do not have their .egg-info metadata with them are increasingly rare, since Python 2.5 distutils creates the .egg-info file by default, and Linux distributions have stopped their former practice of actively deleting the .egg-info files.
let MutableFileNode.__repr__() return something useful even if it isn't not initialize yet
This is because I sometimes log or examine a repr of an object from a function which is being called from that object's own __init__()...
(I'm committing this patch in order to test our patch management infrastructure.)
docs: use "127.0.0.1" instead of "localhost"
Unfortunately there are occasionally configurations in the real world where "localhost" does not resolve to 127.0.0.1, and if a user has such a configuration then using 'localhost' could lead to an authority leak.