[
https://issues.apache.org/jira/browse/COUCHDB-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830803#comment-15830803
]
ASF subversion and git services commented on COUCHDB-3274:
----------------------------------------------------------
Commit 604edd10e28e144c57826630b1d92ab41a9377b9 in couchdb-couch's branch
refs/heads/3274-couch-file-eof from [~rnewson]
[ https://git-wip-us.apache.org/repos/asf?p=couchdb-couch.git;h=604edd1 ]
Reset EOF if a partial write was possible
We can't know if one or more bytes were written by a file:write/2 call
that results in an error and so it is not correct to leave #file.eof
at its original value. In the event of error, use file:position(Fd,
eof) to find the new, true length of the file, and update #file{}
accordingly.
COUCHDB-3274
> eof in couch_file can be incorrect after error
> ----------------------------------------------
>
> Key: COUCHDB-3274
> URL: https://issues.apache.org/jira/browse/COUCHDB-3274
> Project: CouchDB
> Issue Type: Bug
> Reporter: Robert Newson
>
> It's possible for a file:write call to write some of the requested data but
> then return an error ({error, enospc}, for example).
> In 2010 we started tracking eof in couch_file state, where previously we
> called file:position(Fd, eof) and used that value, which was always correct.
> In success cases we advance the eof value by the correct amount but in error
> cases we don't advance it at all.
> A simple fix is to call file:position(Fd, eof) in the error cases and set the
> eof field to that value.
> The upshot of this bug is that data written to the file once eof is wrong is
> essentially corrupt in that we'll look for it at the wrong offsets. Given
> this would typically when a filesystem runs completely out of space, in most
> cases it would not cause issues (we wouldn't be able to write a header that
> pointed to this) but if space were then recovered (and the couch_file had not
> closed or crashed) then corruption seems assured.
> I have a patch for this and I certainly welcome opinions on severity (and,
> indeed, if I'm flat wrong).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
