[PATCH] 8004789 : (zipfs) zip provider doesn't work correctly with file systems providers rather than the default

[Philippe Marschall]

On Tue, Dec 11, 2012 at 10:00 PM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> On Tue, Dec 11, 2012 at 7:05 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 10/12/2012 19:02, Philippe Marschall wrote:
>>>
>>> :
>>>
>>> #toAbsolutePath() is in for two reasons. First it's there in the
>>> existing code and I wanted to change as little as possible to keep the
>>> side effects as small as possible. Second I believe it would be
>>> theoretically possible (and spec compliant) to create a zipfs on a
>>> relative path. In such a case #getParent() may return null. For that
>>> to happen a file system provider would have to support creating
>>> relative paths from an URI. I don't recall any part of the spec that
>>> would forbid this. Path#toUri() describes the behaviour of the default
>>> provider and says all other providers can do what they want. However
>>> you're certainly more familiar with the spec than I am.
>>>
>> The toAbsolutePath is mostly harmless here, but not strictly required
>> because all the Files methods accept relative paths.
>
> Right, but I was mostly concerned with null. Files#createTempFile does
> not accept null as a path. As we want to create the temp file in the
> parent directory of the zip file. So we use:
>
> Files.createTempFile(path.getParent(), …, …)
>
> however when path is relative then #getParent can return null so we
> would end up doing
>
> Files.createTempFile(null, …, …)
>
> which would throw a NullPointerException.
> #createTempFileInSameDirectoryAs has some fallback to do deal with
> null parents however that relies on ".". Path#normalize() mentions
> that some file systems support "." but does not require them to do so.
> So doing #toAbsolutePath() before the fallback seems more robust.

I was encouraged by Ben Evans to bump.

Cheers
Philippe