The patch that i submitted to bug 23392 solves problems connected to unescaped paths in the client. Grab the latest version from CVS.
-----Original Message----- From: Warwick Burrows [mailto:[EMAIL PROTECTED] Sent: quinta-feira, 2 de Setembro de 2004 2:54 To: 'Slide Users Mailing List' Subject: RE: Confirmation for defect 30902? Hi Carlos, I've submitted a fix for the problem and hope to see it added to the HEAD soon. The only reason I can think of for addLock() searching by locktoken is that with shared locks its possible for multiple locks with different lock tokens to be set on the same uri. So when they're looking to see whether to add a locktoken they get back from a propfind on the lock discovery property then they have to key off the locktoken to be sure they don't add the same locktoken twice -- since its perfect valid to have multiple locks on the same uri. And when getting locks for various purposes the client uses the owner that they're given (or "Slide") by default to key off which of the set of tokens that comes back from getLock() apply for the target owner and target resource. Warwick -----Original Message----- From: Carlos Villegas [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 01, 2004 8:15 PM To: Slide Users Mailing List Subject: Re: Confirmation for defect 30902? Yes, I confirm this defect. In fact we fixed it locally the same way you did. We were seen this problem quite often since we are testing japanese characters in paths. We also wonder why the check in addLock() is based on the value, not the key. Is it because if binding is being used a given resource may have several URLs? But in that case, unlockMethod should also search locks by value to be consistent. 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] AVISO Esta mensagem e todos os seus anexos poderá conter informação confidencial para uso exclusivo do destinatário. Se a recebeu indevidamente, elimine-a por favor e informe o emissor. Obrigado. DISCLAIMER This e-mail and attachments may contain confidential information for exclusive use of its recipient. If you have received this e-mail in error, please delete it immediately and notify the sender. Thank You.
