On Thu, Apr 20, 2017 at 2:48 AM, Stefan Bodewig <bode...@apache.org> wrote:
> 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? > > In my debugging the XML parser allowed the null InputStream and took it upon itself to go find the named resource. This caused a weird exception that somehow coincided with the changes to Path and Union to use the Java 8 Stream APIs, prompting me to find and fix this bug. > > 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. > > By "current" do you mean the code that increments past the ':' but not the '/', i.e. until I fixed said bug? > Many thanks > > Not at all, thank you! Matt > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
