Those patches are submitted with defect numbers: 30900, 30902, 30903, 30904 and 30907.
Warwick -----Original Message----- From: Ingo Brunberg [mailto:[EMAIL PROTECTED] Sent: Friday, August 27, 2004 6:17 AM To: [EMAIL PROTECTED] Subject: Re: Slide fixes to be reviewed I'm pretty sure there's no bug related to spaces in pathnames in WebdavResource. But the commmand line client and the LockMethod may well have problems. I will have a look at the patches as soon as Warwick submits them. Ingo > 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]
