[ https://issues.jboss.org/browse/JBIDE-17148?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-17148: ------------------------------------- Unfortunately the way to test this now depends on who is calling it. We know that both central and stacks use this api, and also download runtimes (when downloading a jboss server). Essentially, each caller can pass in a custom folder to store and cache the downloaded file. Each folder is given an index file, as well, to keep track of which files in the folder are actually in the cache vs which ones are not. And the names given to the downloaded files are now more representative of their urls, so instead of a random tmp8235478345734.tmp file, the downloaded file's name is now more similar to a url (such has http___www.x.com_someFolder_file.jar.tmp. Much of this is internal implementation details, though you can still search at least for URLTransportCache.cacheIndex.properties somewhere in your metadata folder after stacks, runtimes, or central download any remote web file for use. I'm not re-opening the issue, because there's no clear steps to check, but, if you wanted to look into it, I'd suggest finding folders that have URLTransportCache.cacheIndex.properties as a file, looking at the contents of the folder and the contents of the file, and verifying that 1) The file names are easily readable, and 2) the index file contains whatever is in the folder. I would also try canceling a download and verifying that the index file does not contain that file (that the object is only added to the cache index AFTER the download completes). I will not re-open this issue, though you can if you intend to verify. -- This message was sent by Atlassian JIRA (v6.2.3#6260)