[ https://issues.jboss.org/browse/JBIDE-22713?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-22713: ------------------------------------- The only way the code manages to get to line 203 with extractIfNeeded in the stack only once is if extractedFile is not a file, and, it is not the case that extracted=true && overwrite==false. Importantly, the stacktrace only lists extractIfNeeded once. This means it didn't recurse into itself. It failed on the first pass. In order to reach that error on the first pass, overwrite must be true, or, extracted must be false. A call heirarchy and grep of the code indicates that there are no callers, other than the recursive call, where overwrite=true. This means, since there is only one extractIfNeeded, overwrite must be false. If overwrite is false, the line 203 exception cannot be reached unless extracted is also false. 'extracted' gets its value on line 193. A value of false here means either the destination folder does not exist, or, the destination folder is a file. In either case, the code would attempt to enter lines 195/196 and extract. If the destination folder was in fact a file, the UnArchiver would throw an exception while trying to extract a zip into a file location... like below: {code} java.io.FileNotFoundException: /home/rob/apps/eclipse/workspaces/runtime-New_configuration/.metadata/.plugins/org.jboss.tools.central/central/d794065/css/jboss-app.css (Not a directory) at java.io.FileOutputStream.open0(Native Method) at java.io.FileOutputStream.open(FileOutputStream.java:270) at java.io.FileOutputStream.<init>(FileOutputStream.java:213) at java.io.FileOutputStream.<init>(FileOutputStream.java:162) at org.jboss.tools.project.examples.internal.UnArchiver.extract(UnArchiver.java:109) at org.jboss.tools.central.internal.CentralHelper.extractIfNeeded(CentralHelper.java:196) {code} Because such an exception is not thrown, we can assume it is not a file. Therefore, we can deduct that the folder did not exist before attempting to extract, and, at least the index.html still does not exist after it attempts to extract. The only way I can imagine this happening is if the file to be extracted somehow is wrong. Looking at the code, well... I just can't imagine it's correct, specifically getEmbeddedFilePath. There are dozens of implementations of this type of method in our codebase alone, and none of them look like this. Manually replacing the space with a %20 seems wrong. In fact, using an intermediate URI at all also seems wrong. -- This message was sent by Atlassian JIRA (v7.5.0#75005)