8225461: (fs) Investigate filtering duplicates out of Iterable returned by java.nio.file.FileSystem::getFileStores

[Brian Burkhalter]

> On Jun 11, 2019, at 10:25 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
>> On Jun 11, 2019, at 3:46 AM, Alan Bateman <Alan.Bateman at oracle.com <mailto:Alan.Bateman at oracle.com>> wrote:
>> 
>>> I don’t know whether the specification of FileSystem::getFileStores() should be updated to indicate that no duplicate stores are returned, which would necessitate a CSR.
>>> 
>> This issue is going a bit of time to review as it changes the meaning of equals/hashCode and has several other implications that will take time to work through. I will try to get to it soon, but maybe not this week.
> 
> Understood. Note that the new equals() and hashCode() methods in UnixMountEntry are identical to the respective methods of UnixFileStore.

Reprising the thread about [1] starting from the message [2]. Un updated patch is at [3]. Contrary to the previous version, this patch does not change any implementation code and does *not* attempt to keep duplicates out of the results of getFileStores(). Instead this is allowed to remain a reflection of the contents of /proc/mounts (or /etc/mtab) on Linux.

The test code is restructured to replace the FileUtils method areAllMountPointsAccessible() with getNumReplicateMountPoints(). If duplicate FileStores are detected, then no exception is thrown unless the number of replicates does not match that obtained directly from /proc/mounts. This approach should also address [4].

One thing I noticed which I don’t know is correct is that sun.nio.fs.LinuxFileSystem.getMountEntries() uses /etc/mtab but sun.nio.fs.LinuxFileStore.findMountEntry() uses /proc/mounts. On my local Linux VM both of these point to /proc/self/mounts but that might not be the case on other systems.

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8225461
[2] http://mail.openjdk.java.net/pipermail/nio-dev/2019-June/006282.html
[3] http://cr.openjdk.java.net/~bpb/8225461/webrev.01/
[4] https://bugs.openjdk.java.net/browse/JDK-8225471
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/nio-dev/attachments/20190809/0ac88691/attachment.html>