User A locks a file. User B attempts to unlock the file. Unlock attempt fails with a 423 Locked error, rather than succeeding with a 204 No Content response. User B does have the necessary security permissions to unlock the file locked by user A. The functional test killLock.xml directly tests this case and fails using the mem configuration. Looking at the code, it appears that the lock cache used by LockImpl#checkLock () is not updated/invalidated after the unlock operation modifies the underlying information. In fact, it appears that entries in this cache are never updated/invalidated after they are first entered, so there may be other problems. Commenting out use of the cache as follows works around the problem: 373,384c373,381 < // Removed all use of lock cache, since it is not invalidated correctly. Results in the inability < // to release another user's lock, even when you have the appropriate permission. < < // Boolean locked = token.checkLockCache(object, action); < // if (locked != null) { < // if (locked.booleanValue()) { < // throw new ObjectLockedException(object.getUri()); < // } < // else { < // return; < // } < // } --- > Boolean locked = token.checkLockCache(object, action); > if (locked != null) { > if (locked.booleanValue()) { > throw new ObjectLockedException(object.getUri()); > } > else { > return; > } > } 389c386 < // try { --- > try { 391,396c388,393 < // token.cacheLock(object, action, false); < // } < // catch (ObjectLockedException e) { < // token.cacheLock(object, action, true); < // throw e; < // } --- > token.cacheLock(object, action, false); > } > catch (ObjectLockedException e) { > token.cacheLock(object, action, true); > throw e; > } Note that the line numbers here are not accurate.
This problem was found in the nightly build from 20051005042448.
In fact, I would expect that this problem you described was instead a wanted feature. If a principal does a lock on a file, he means to maintain it, not loosing it to the first 'pirate' or accidental user that tries to write into it. Anyway, if you would like to have that behavior you could always make every user of the default role 'root' or adding them the acl 'unlock' permission. ps: i'm no developer
My understanding of the submitter's explanation of the problem is that the user B does have the "kill lock" permission that would normally allow them to unlock the lock owned by A and the bug is that they are not permitted to do this because of a caching issue. The kill lock permission would be used by admin users to remove a lock owned by a person who has left the company for example.
You're right ^^ I've failed to notice that the user B had the necessary security permissions.