Hi Filip, Haroon, as far as I understand, the problem is a copy operation which copies one file on itself. Haroon showed that this is happing in his case. Unfortunately, it it not proved that this is happening in all cases. Furthermore, the removal of the second copy operation could still cause a regression in other cases.
Maybe we could fix the bug in a more secure way: How about adding a check to the copy()-method, so that it can no more delete a file by copying on itself? We could: 1. just ignore the copy if the 2 paths are the same 2. throw an IllegalArgumentException if the 2 paths are the same Personally, I would prefer the second solution, because it make errors like this one better to find in the future. The two code-lines removed by Haroon could have a try-catch-block to ignore the IllegArgExc here (with a bold FIXME-Message to the log!) *** I suggest to be very careful in changing this part of tomcat. This case proves again, that the test-coverage in the manager code is not pretty good. Mainly because there are many configuration and deployment scenarios, which affect its behavior. (I suffered a similar case some days ago) *** Please tell, if I can help Reinhard Am Mittwoch, 22. März 2006 00:54 schrieb Filip Hanik - Dev Lists: > aah got it, in that case, > > +1 > > to get this fixed, > will wait a day or two, if no minus one votes come up, I'll apply it for > you, just remind me :) > > Filip > > Haroon Rafique wrote: > > On Today at 4:02pm, FHDL=>Filip Hanik - Dev Lists <[EMAIL PROTECTED]> > > wrote: > > > > FHDL> Question, if you remove the lines you mentioned, does the > > FHDL> application get deployed in your local instance, the one where the > > FHDL> manager servlet runs? Cause the line that is removed is where the > > FHDL> war is copied to the appbase of the host. > > FHDL> > > > > > > Hi Filip, > > > > Thanks to you too for responding. I don't really understand your > > question. With my "fix", the application gets deployed in the regular > > place (webapps directory) and I can see it under the manager servlet as > > well. I'm not quite sure what you mean by local instance?? > > > > The copy() line that is removed: > > > > copy(localWar, new File(getAppBase(), basename + ".war")); > > > > is pretty misleading. At this point, the value of localWar (the first > > argument) and new File(GetAppBase(), basename + ".war") is exactly the > > same. So, the call in fact clobbers a perfectly valid war file with a new > > 0-length file. In pseudo-code I can translate that to copy from an > > already existing war file onto itself (creating a new one in the process) > > and eventually end up with a 0-length file. As I explained in one of my > > earlier emails, the copy to appbase of the host has already happened in > > the previous copy() method call with no problems. > > > > As a test I put a Thread.sleep(20000) in between the 2 copy methods and > > sure enough, the war file is full-length in the webapps directory after > > the 1st call and 0-length after the 2nd call. > > > > FHDL> > > FHDL> I haven't had time to run through this patch, but there should be a > > FHDL> -1 if we don't want it, and an explanation along with that. > > FHDL> > > FHDL> so I am +0 on it, since don't have time to test it > > FHDL> > > > > :-( Sorry to hear that, but at least you responded. Neutral is better > > : than > > > > negative. > > > > FHDL> > > FHDL> Filip > > FHDL> > > > > Cheers, > > -- > > Haroon Rafique > > <[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] -- Reinhard Moosauer IT Beratung --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
