[ http://issues.apache.org/jira/browse/DERBY-1392?page=all ]
Anders Morken updated DERBY-1392:
---------------------------------
Attachment: DERBY-1392-1.patch
M java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java
DERBY-1392-1.patch moves the updatePageArray call outside the try/catch block
around the writes, so both writes can write the same data. storeall passes.
> Corner case behaviour in RAFContainer#writePage() can cause invalid data to
> be written to data files
> ----------------------------------------------------------------------------------------------------
>
> Key: DERBY-1392
> URL: http://issues.apache.org/jira/browse/DERBY-1392
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.2.0
> Environment: Platforms that throw an IOException when writing beyond the
> EOF, but permit the write to proceed if the file is padded, then written.
> Reporter: Anders Morken
> Assignee: Anders Morken
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: DERBY-1392-1.patch
>
> java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java#writePage(...)
> will
> attempt to retry a write if an IOException is thrown on the first attempt.
> However, the next
> attempt does not add container header data to the first page, nor does it
> encrypt the data
> if the database is encrypted.
> I'd expect this bug to be case silent corruption of encrypted databases if
> the code path
> was actually exercised. The fact that this bug still lives and nobody has
> discovered it is
> possibly an indication of how uncommon this code path is. Since the comment
> in the code
> says nothing about exactly what platforms the workaround was intended for, I
> don't know if
> these platforms are still supported for Derby. There's also a workaround for
> an EPOC Java
> bug earlier in the code - EPOC only had a Java 1.1 VM, which is no longer
> supported.
> I'll attach a patch for the issue, but I wonder if we might as well remove
> the "retry code path"
> if it is never used?
> (If you're paranoid, this could also be considered a security issue. If
> someone could
> cause IO errors for Derby at will, they could make Derby write the database
> without
> encryption - but there are far easier ways to attack Derby if you've got that
> kind of
> access, so I'm discounting that. =)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
