retitle 701350 Data corruption with eglibc 2.17 thanks The unit test in question fails when using eglibc 2.17, independent of the gcc version.
The reason is a bug in src/s3ql/_deltadump.pyx, which repositions a file descriptor associated with a FILE* stream without first calling fflush(). I do not understand why this problem does not show up when using eglibc 2.13. I think relying on this to work is not a good idea, because if it ever becomes a problem (without a rebuild of S3QL), s3ql will suddenly store malformed metadata that cannot be loaded again. 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. I'm not sure if I should bump the severity to grave (even though it looks as if it should cause data loss, things seem to work as long as eglibc 2.13 is used), but I'll try to get the necessary patch into wheezy. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
