> -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Thursday, June 20, 2013 1:03 PM > To: dev > Subject: Re: fixPath (was: committer wanted for review) > > Yes, got it. It is quite big. It is dealing with more than just a path > format, isn't it? > Yah, I agree the patch changes too much(join path, and remove double quote, all over the places).
> > On Thu, Jun 20, 2013 at 8:53 PM, Edison Su <edison...@citrix.com> wrote: > > > I uploaded the patch to dropbox: > > https://www.dropbox.com/s/d9fn17xmho19fdc/cloud-3.0.1- > bug14066.patch, > > can you access it? The patch is cooked by Fred Wittekind < > > r...@twister.dyndns.org> one year ago. > > > > > -----Original Message----- > > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > > Sent: Thursday, June 20, 2013 12:13 AM > > > To: dev > > > Subject: Re: fixPath (was: committer wanted for review) > > > > > > I am not authorized to access the link you are sending Edison, but > > interested > > > in the contents. Could you send it please? > > > > > > > > > On Wed, Jun 19, 2013 at 10:26 PM, Edison Su <edison...@citrix.com> > > wrote: > > > > > > > The double slash can happen in every where, there is bug fix long > > > > time ago( http://bugs.cloud.com/show_bug.cgi?id=14066), which > > > > tries to change all the path concatenation, unfortunately, it's > > > > not been checked into cloudstack. > > > > I am +1 with your patch, which at least fixes this particular > > > > issue, without changing too much code. > > > > > > > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > > > Sent: Wednesday, June 19, 2013 12:38 PM > > > > To: dev > > > > Subject: fixPath (was: committer wanted for review) > > > > > > > > John and others, > > > > I have been looking for the point where the wrong path is instantiated. > > > > After analyses I came to the DownloadAnswer class which contains > > > > the original fixPath method that I c&p'ed to do my thing. I cannot > > > > support this with logging however. Where the DownloadAnswer is > > > > created eludes me however. I got trapped between > > > > DownloadManagerImpl and > > > DownloadListener. > > > > The creation of the answer was as far as I could tell in > > > > handleDownloadProgressCmd but again I can not support this with > > logging. > > > > As the reason I suppect eclipse class-file caching but also this > > > > theory seems to not work. > > > > Anyone's got a good clue for me? > > > > > > > > I have burned to much time on this so I will save the patch for if > > > > it is locally needed by users, but I still want to find the best > > > > solution. > > > > As for John's argument of creating technical debt, I am now > > > > convinced that I am not adding but only using the present debt that is > > > > in > there. > > > > The > > > > DownloadAnswer.fixup() method is doing the same on a more obscure > > > > place then my solution. > > > > > > > > Also, if we decide to apply my changes anyway I think we should up > > > > the loglevel at least as much as acceptable as to keep pointing to > > > > the technical debt that we have at the moment. > > > > > > > > On Tue, Jun 18, 2013 at 5:28 PM, Daan Hoogland > > > > <daan.hoogl...@gmail.com <mailto:daan.hoogl...@gmail.com>> > wrote: > > > > On 2013/6/18 16:49 , John Burwell wrote: > > > > > > > > Second, please don't take my feedback as passing judgements such > > > > as things being ugly or don't worry, I like the discussion and i > > > > don't mind losing an argument if the best solution arises from it. > > > > Let's see about that. > > > > -- > > > > [cid:part1.06080303.01090409@gmail.com]<http://daan.sbpad6.nl/> > > > > > > > > > >
