jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaka Jaksic (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-551) Null values cause BLOB corruption
Date Fri, 01 Sep 2006 23:54:23 GMT
    [ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12432261 ] 
Jaka Jaksic commented on JCR-551:

Hey, Stefan.. This is rather embarrassing, but as I went to prepare the stand-alone test case,
I was unable to reproduce it either. I used the same configuration (as much as I could), but
no matter what I did, if I set the property to null, the BLOB was simply deleted, just like
it should be. I really don't know what could have made the difference in my application (the
bug was perfectly reproducible there - occured plenty of times in a fresh repository etc.),
and I still think this bug does exist, but it is obviously not as common and as critical as
I thought. So let's just leave it at that for now and I'll get back to you if I manage to
learn more about it. I'm really sorry for wasting your time.

> Null values cause BLOB corruption
> ---------------------------------
>                 Key: JCR-551
>                 URL: http://issues.apache.org/jira/browse/JCR-551
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.0.1
>            Reporter: Jaka Jaksic
>         Assigned To: Stefan Guggisberg
>            Priority: Critical
> Using the file persistence manager (not sure about other managers) there is a way to
produce a corrupt property BLOB, which can then be neither read nor modified nor deleted.
Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every
time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g.
with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String,
> For example:
>     node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the
BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as
documented in the JCR spec. I think other overloads should do the same, although this is not
explicitly stated in the spec. In any case they should not corrupt repository data.

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


View raw message