]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
tahoefuse: fix typo which could cause data corruption
authorrobk-tahoe <robk-tahoe@allmydata.com>
Wed, 7 May 2008 23:42:20 +0000 (16:42 -0700)
committerrobk-tahoe <robk-tahoe@allmydata.com>
Wed, 7 May 2008 23:42:20 +0000 (16:42 -0700)
commitabae0345adb03033d28052fd34191a4c4632364a
treed1c6782dc6d0c3bbd2bbeeee2c69e445393f14f0
parent8179daee4adf1a3224d3e2666a8a296d76ea6179
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.
mac/tahoefuse.py