[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 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.

Cheers
Philippe