Data corruption with eglibc 2.17

[Impact]

The S3QL package in raring destroys user data.

There is a bug in src/s3ql/_deltadump.pyx, which repositions a file descriptor associated with a FILE* stream without first calling
fflush(). When using eglibc 2.17, this means that s3ql will store malformed metadata that cannot be loaded again (with prior eglibc versions the bug does not appear, which is probably why it hasn't been found until now).

The problem is made worse because this affects only the metadata uploaded to the remote server, but not the locally cached copy. So unless the user explicitly tests reloading the metadata from the server, the corruption will not show up until it's too late.

The attached patch fixes the problem by adding the missing fflush() call.

[Test Case]

 * The bug is detected by S3QL unit tests, so running "setup.py test" will fail with

$ ./setup.py test
[...]
======================================================================
ERROR: test_1_vals_1 (__main__.DumpTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "t1_dump.py", line 36, in test_1_vals_1
    self.compare_tables(self.src, self.dst)
  File "t1_dump.py", line 155, in compare_tables
    (id2, buf2) = i2.next()
  File "/usr/lib/s3ql/s3ql/database.py", line 250, in next
    for col in self.cur.next() ]
StopIteration

The unit tests are run automatically by debian/rules. This bug only made it into the release because (presumably) S3QL was build before eglibc was updated to 2.17.

[Regression Potential]

 * The patch effects the writing and reading of data from a binary dump file into an SQLite database. Any regression would thus be restricted to the initial reading, or final dumping of the data. While this makes testing easier, it also means that any regressions will probably make the entire program unusable.

[Other Info]

 * The same patch has already been applied to the S3QL 1.11 debian package.