8162520: (fs) FileStore should support file stores with > Long.MAX_VALUE capacity

[Brian Burkhalter]

> On Oct 14, 2019, at 1:51 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 11/10/2019 01:22, Brian Burkhalter wrote:
>> An updated version is here http://cr.openjdk.java.net/~bpb/8162520/webrev.02/ <http://cr.openjdk.java.net/~bpb/8162520/webrev.02/>. This changes the various get*{Blocks,Space}() methods to return Long.MAX_VALUE if the respective size would overflow a long. The patch passes all the java.nio tests on all platforms.
> Thanks, I think this is probably the best of the options so far.
> 
> The new methods need to link to getBlockSize to find out what a block is. In the javadoc, the "In this case" sentence seems to suggest that the new methods should be used as a fallback when MAX_VALUE is returned. I think we need to adjust this wording to make it clearer that the getXXXBlocks methods is the recommended way to get the space information. Minor nit in the @implSpec is "throws UOE" rather than "throws an UOE" might be better.

An updated version which addresses the foregoing points is at http://cr.openjdk.java.net/~bpb/8162520/webrev.03/ <http://cr.openjdk.java.net/~bpb/8162520/webrev.03/>.

> The File.getXXXSpace methods will need attention too, maybe a separate issue to clarify their specs, fix the implementation, and link them to the methods in FileStore.

I filed https://bugs.openjdk.java.net/browse/JDK-8232271 <https://bugs.openjdk.java.net/browse/JDK-8232271> to address this.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20191015/b99a4efa/attachment.html>