Hi I was having trouble with pathnames and spaces too, i'm designing an app, and started by implementing the methods on top of the slide client, but some didn't seem to work at all. Later i associated the bad behaviour with the spaces in the filenames. For instance, using the commandline client I'm getting this error when i try to do some operations on a pathname that contains spaces:
"[LOCALHOST:/slide/files/Folhas Soltas/] C:\ $ report tabacaria.txt Getting version-tree Report of '/slide/files/Folhas Soltas/tabacaria.txt': Error: escaped absolute path not valid" I suppose this is connected to the bug you refered in "WebdavResource.java"? This error of course doesn't show up when there aren't any spaces in the pathname. Do you think these patches will solve the problem? please submit them quickly :) Thanks again -----Original Message----- From: James Mason [mailto:[EMAIL PROTECTED] Sent: sexta-feira, 27 de Agosto de 2004 7:39 To: Slide Users Mailing List Subject: Re: Slide fixes to be reviewed Warwick, Bugzilla is the best option for submitting fixes. It makes it easier to track which fixes have been applied and which are pending. It's a bit of work, but if you can create a bug for each change you've made that will be the easiest to keep track of. Otherwise just create a single bug and attach all your changes and we'll keep track of what's been done in the comments. Thanks for doing this, btw. I absolutely love it when someone submits a bug *with* a patch :). -James Warwick Burrows wrote: > Hi James, > > I actually have a number of fixes that I've made to get Slide working in my > configuration. I'd like to submit them all but would like to have them > reviewed by a slide contributor first to make sure that they are ok. How do > I get them to the list as I haven't been able to send a zip or tar file > attachment as they get bounced. > > Here's a summary of each change for context: > > > WebdavResource.java: > ------------------- > - Found a problem establishing "existence" of paths with spaces in > them. Eg. "My Files". The path coming back from the server was escaped and > getPath() returns an unescaped string. Was failing to set existence as a > result. Decode and compare the two on a common basis. > - got a "wild-hare" about the the way a trailing '/' on one of the > paths is dealt with so I changed it to make it a little faster and skips > cases where the strings are definitely not equal regardless of the '/'. > - added a lockMethod with a depth parameter to lock subdirs and > their children. > - added discoverOwnLocks with an owner parameter to get locks for a > specific user and which is not the user in my client context (ie. no authn > or authz is being used). > > > LockMethod.java: > ---------------- > - similar to existence prob in WebdavResource.java for paths with > spaces. The lock is stored in the hashmap by parseResponse with an escaped > path. The check for existence of a lock on the resource uses an unescaped > path so it wouldn't find the lock. I changed it to add the lock to the > hashmap with the unescaped path so that its found. > > > DOMUtils.java: > -------------- > - lock owner not being read out of response from server because > owner value was "escaped" using CDATA decl. DOMUtils was only looking for > text responses. > > > Client.java: > ------------ > - couple of simple checks for null object refs. > > > DB2RDBMSAdapter: > ---------------- > - check for null ref in case of empty result. > - override CommonRDBMSAdapter version of > convertRevisionNumberToComparable() with one using SQL functions supported > by DB2. > > > Thanks, > Warwick > > > -----Original Message----- > From: James Mason [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 25, 2004 10:43 PM > To: Slide Users Mailing List > Subject: Re: lock owners not returned with lock properties in 2.1b1?? > > > Warwick, > Can you provide a patch for this? > > Thanks. > -James > > Warwick Burrows wrote: > >>Looking for CDATA node types works. I just added it as an OR >>condition. This problem may have arisen for me since we use numerical >>owner codes and perhaps the server decided to wrap it in a CDATA >>definition for that reason... I don't know. >> >>Warwick >> >> >> >>-----Original Message----- >>From: Warwick Burrows [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, August 25, 2004 2:26 PM >>To: 'Slide Users Mailing List' >>Subject: RE: lock owners not returned with lock properties in 2.1b1?? >> >> >> >>I've tracked this down to the code that processes lockdiscovery >>properties returned in the propfind. There is a call to >>DOMUtils.getTextValue() in LockDiscoveryProperty.java and this call is >>returning NULL instead of the CDATA that was returned by the server in >>the D:owner element. Its because the code is checking whether the >>element is a text node and only returning the value if it is. Since >>the D:owner contains CDATA its not matching and returning a NULL result > > instead. > >>If anyone has already fixed this then let me know otherwise I'm going >>to see whether changing getTextValue() to look for CDATA nodes as well >>will fix it. >> >>Warwick >> >> >> >>-----Original Message----- >>From: Warwick Burrows [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, August 25, 2004 10:30 AM >>To: 'Slide User Group ([EMAIL PROTECTED])' >>Subject: lock owners not returned with lock properties in 2.1b1?? >> >> >>Hi, >> >>It seems that lock owners are not returned from the server with the >>other lock information any more. I've seen this from the CLI and from >>within my own application. I noticed it when the application that I >>had working with 2.1M1 stopped working with 2.1B1. When I lock a >>resource with an owner using "-o<name>" the command succeeds and a >>locktoken comes back. But when I run "locks" on the object the owner >>name is empty. Has anyone else seen this problem or can suggest why >>this is happening? I'm running with security checking disabled but I >>don't see why that would affect locking which is enabled. >> >>Thanks, >>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] >> >> >> > > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- 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.
