On 2017-04-19, Matt Benson wrote:

> I had forgotten about this. When testing my other changes I noted that no
> InputStream was returned here, due to the requested entry name including
> the leading slash from the jar resource URL; the jar entries encountered
> during testing, at least, lacked the leading slash.

So this has never worked and nobody has noticed so far, strange.

> Due to this the actual reading of the resource was deferred to the XML
> parser. Skipping the slash fixed this issue for me and seemed
> anecdotally to decrease the amount of time needed to run the
> tests.

Wouldn't we end up with a null InputStream and an exception being thrown
later on?

> You of course know much more about the file format than I; I have been
> unable to find a definitive resource that confirms that jar file
> entries should always lack a leading separator.

A leading slash would violate the ZIP spec

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT

       4.4.17.1 The name of the file, with optional relative path.
       The path stored MUST not contain a drive or
       device letter, or a leading slash. ...

so the current code is certainly wrong. I'll try to dig deeper into this
the coming days unless anybody else beats me to it.

Many thanks

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Reply via email to