BTW, supporting japanese required adding lots of workarounds for MS Webfolders. Some versions of japanese WebFolders send paths encoded inconsistently in UTF8 or Shift_JIS, sometimes even unescaped. We basically had to auto-detect the encoding and escaping of the URLs sent by WebFolders.
Cheers,
Carlos
Warwick Burrows wrote:
Hi,
I was wondering if someone would confirm a defect that I still see in the 2.1B1 release. This is related to defect number 30902 "lock for space separated paths not found" that I've submitted a fix for. Using the CLI I've created a collection called "my stuff" and uploaded a file to it called "testf". I then locked the file with the options "-o10000 -sexclusive -tinf" and then check that the lock has worked with the "locks" command. It did. When I try to unlock the file with "-o10000" I get a 200 code back but there is a message saying "failed" and the file is still locked. I'm running on windows 2000 sp4.
The reason for this is that in LockMethod.parseResponse() the lock is being
added to the lock hashmap by WebdavState.addLock() with the escaped URI of
the file as the hash key. ie. the space is escaped with %20. The call that
returns this escaped URI to use with addLock() is
org.apache.commons.httpclient.HttpMethodBase.getPath() which (from the
javadoc for the corresponding setPath() method) returns a raw (escaped) path
-- or at least it expects it to be escaped if necessary by the caller.
So when looking for the lock in WebdavResource.unlockMethod() we use the unescaped URI to check for the existence of the lock in the hashmap when calling WebdavState.getLock(). The lock was put in the hashmap with the escaped URI as the key so its not found. The solution is to always use the same hash key. Either the escaped or unescaped URI. In my fix I chose the unescaped URI as that is most commonly used in the client and I'd only seen this one case where addLock() was called with an escaped path.
Funny enough we do find the lock entry in WebdavState.discoverLock() when we process the locks that come back from the lockdiscovery property call in WebdavResource.unlockMethod(). And we don't add a second lock entry for the same token because in the second call to WebdavState.addLock() the addLock code checks for the existence of this locktoken by checking for its value, not by the hash key.
Warwick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
