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

Philippe Marschall philippe.marschall at gmail.com
Mon Dec 10 11:02:23 PST 2012

On Mon, Dec 10, 2012 at 12:06 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 09/12/2012 22:08, Philippe Marschall wrote:
>> Hi
>> As discussed previously [1] here are the patches against JDK 7 and 8
>> to make the ZipFileSystem provider use Files#createTempFile instead of
>> File#createTempFile. This causes the temporary file to be created on
>> the same file system as the ZIP file resides on. This makes it
>> possible to run the zipfs provider on a file system other than the
>> default one.
>> This patch does not include any tests but I also could not find any
>> existing ones. If somebody wants tests I'd be happy to supply them
>> once instructed who to do them and where to put them.
> Thanks for the patch, it looks okay to me. I see that toAbsolutePath is used
> but that isn't actually required. Sherman - do you want to sponsor this?

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


More information about the nio-dev mailing list