using both small and large blocksizes for writes, write a 1Mb file to fuse
where every write overlaps another.
This serves a useful purpose - in manual testing of blackmatch some time ago
most operations e.g. bulk copies, worked fine, but using rsync caused data
corruption on most files. it turned out to be that rsync writes in 64K blocks,
but rather than making the last block short, the last block instead overlaps
the preceding (already written) block. This revealed a problem where cache
files were being opened 'append' rather than 'write' and hence the overlapping
write to the fuse layer caused the overlapping portion of the file to be
duplicated in cache, leading to oversized and corrupt files being uploaded.
unit tests to test writing contiguous blocks linearly through the file,
for a variety of block sizes; 'tiny_file' is an entire file fitting within
a single io block / write operation. 'linear_{small,large}_writes' test
a 1Mb file written with each write operation containing significantly less
or more, respecitvely, data than fuse will pass into the implementation as
a single operation (which on the mac at least is 64Kib)
this performs a very simple write through the fuse layer and confirms that
the file is stored correctly into the tahoe mesh. ('simple' in the sense
that the entire file body fits trivially in a single write() operation,
disk block etc)
similar to the --debug-wait option which causes the test harness to
pause at various stages of the process to facilitate debugging, this
option simplifies that debugging by automatically opening a web browser
to the root dir of that implementation's tests when tests are commenced.
in addition, if --web-open is specfied but --debug-wait is not, the
harness will still pause after running tests but before tearing down
the tahoe grid - this allows all tests to run to completion, but
provide a debugging hook to investigate the end state of the grid's
contents thereafter.
from my examination of the tahoe_fuse ('impl_a') code, it looks like
the intention is to cache the file contents in memory while it's open,
since it does in fact do that. however it looks like it also ignored
that cache entirely, and made an individual tahoe webapi GET request
for each and every read() operation regardless of the relative size of
the read block and the file in question.
this changes that to make read() use the data in memory rather than
fetch the data over again. if there's something more subtle going
on, please let me know.
a handful of code cleanup, renaming and refactoring. basically consolidating
'application logic' (mount/unmount fs) into the 'MacGuiApp' class (the wx.App)
and cleaning up various scoping things around that. renamed all references to
'app' to refer more clearly to the 'AppContainer' or to the guiapp.
globally renamed basedir -> nodedir
also made the guiapp keep a note of each filesystem it mounts, and unmount
them upon 'quit' so as to cleanup the user's environment before the tahoe node
vanishes from out underneath the orphaned tahoe fuse processes
this changes the 'open webroot' menu item to be a submenu listing all aliases
defined in ~/.tahoe. Note that the dock menu does not support submenus, so it
only offers a single 'open webroot' option for the default tahoe: alias.
I had trouble with this at first and concluded that the submenus didn't work,
and made it a distinct 'WebUI' menu in it's own right. on further inspection,
there are still problems but they seem to be something like once the dock menu
has been used, sometimes the app's main menubar menus will cease to function,
and this happens regardless of whether submenus or plain simple menus are used.
I have no idea what the peoblem is, but it's not submenu specific.
These constraints were originally intended to protect against attacks on the
storage server protocol layer which exhaust memory in the peer. However,
defending against that sort of DoS is hard -- probably it isn't completely
achieved -- and it costs development time to think about it, and it sometimes
imposes limits on legitimate users which we don't necessarily want to impose.
So, for now we forget about limiting the amount of RAM that a foolscap peer can
cause you to start using.
Remove some obsolete parts (correct at the time, now incorrect), change terminology to reflect my preference: s/vdrive/filesystem/ and s/dirnode/directory/, and make a few other small changes.
