JDK-8073078 : java/nio/file/FileStore/Basic.java sensitive to NFS configuration
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_11
  • CPU: x86_64
  • Submitted: 2015-02-12
  • Updated: 2019-09-04
  • Resolved: 2015-07-31
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8 JDK 9 Other
7u231Fixed 8u221Fixed 9 b77Fixed openjdk8u222Fixed
Related Reports
Duplicate :  
Duplicate :  
This test failure was spotted in a JDK9 Aurora Adhoc job:

    This test failed due to "ava.nio.file.NoSuchFileException: /tmp/common1".

Here is a snippet of the .jtr file:

/ (rpool/ROOT/solaris) (name=rpool/ROOT/solaris type=zfs)
/devices (/devices) (name=/devices type=devfs)
/dev (/dev) (name=/dev type=dev)
/system/contract (ctfs) (name=ctfs type=ctfs)
/proc (proc) (name=proc type=proc)
/etc/mnttab (mnttab) (name=mnttab type=mntfs)
/system/volatile (swap) (name=swap type=tmpfs)
/system/object (objfs) (name=objfs type=objfs)
/etc/dfs/sharetab (sharefs) (name=sharefs type=sharefs)
/lib/libc.so.1 (/usr/lib/libc/libc_hwcap1.so.1) (name=/usr/lib/libc/libc_hwcap1.so.1 type=lofs)
/dev/fd (fd) (name=fd type=fd)
/var (rpool/ROOT/solaris/var) (name=rpool/ROOT/solaris/var type=zfs)
/tmp (swap) (name=swap type=tmpfs)
/bpool (bpool) (name=bpool type=zfs)
/export/local (bpool/export_local) (name=bpool/export_local type=zfs)
/rpool (rpool) (name=rpool type=zfs)
/scratch (rpool/scratch) (name=rpool/scratch type=zfs)
/media/ORACLE_SSM (/dev/dsk/c4t0d0p0:1) (name=/dev/dsk/c4t0d0p0:1 type=pcfs)
/tmp/common1 (rwsnas429:/export/local) (name=rwsnas429:/export/local type=nfs)
java.nio.file.NoSuchFileException: /tmp/common1
	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
	at sun.nio.fs.UnixFileStore.readAttributes(UnixFileStore.java:111)
	at sun.nio.fs.UnixFileStore.getTotalSpace(UnixFileStore.java:118)
	at Basic.doTests(Basic.java:118)
	at Basic.main(Basic.java:43)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:745)

JavaTest Message: Test threw exception: java.nio.file.NoSuchFileException: /tmp/common1
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.nio.file.NoSuchFileException: /tmp/common1

RULE java/nio/file/FileStore/Basic.java Exception java.nio.file.NoSuchFileException: ...
Fix Request This patch improves test reliability in 8u and keeps codebases in sync (I see 8u221/222). Patch applies cleanly to 8u and passes the affected test on Linux x86_64.

Review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2015-July/003237.html.

If it is not possible to guarantee that a mount point is not deleted between the call to getFileStores() and getTotalSpace(), and getFileStores() contains a fixed list, then I don't know that a fix is even possible. In such a case the iteration will still contain the store which has been deleted. I wonder whether it is perhaps acceptable to ignore the NoSuchFileException in this case: FileStore prev = null; for (FileStore store: FileSystems.getDefault().getFileStores()) { System.out.format("%s (name=%s type=%s)\n", store, store.name(), store.type()); try { // check space attributes are accessible store.getTotalSpace(); store.getUnallocatedSpace(); store.getUsableSpace(); } catch (NoSuchFileException ignored) { // store has been deleted since iterator was created. }

With no modification to the source base I was able to reproduce the problem by unmounting an NFS file system and deleting its mount point between the return from the call to UnixFileSystem$FileStoreIterator.readNext() and the call to FileStore.getTotalSpace(). If the file system is unmounted but the mount point is not deleted, then the test succeeds.

Initial review thread: http://mail.openjdk.java.net/pipermail/nio-dev/2015-July/003221.html

While the documentation of FileSystem.getFileStores() states "When an I/O error occurs, perhaps because a file store is not accessible, then it is not returned by the iterator. " it does not look as if UnixFileSystem$FileStoreIterator.readNext() does anything to validate that the returned FileStore is accessible aside from checking that the mount point of the UnixMountEntry from which the FileStore is derived is readable in terms of Java permissions alone. In the case of Windows, it appears that GetVolumeInformation() - more or less the equivalent of statvfs() - is invoked from WindowsFileStore.create() which is called in WindowsFileSystem$FileStoreIterator.readNext(). If WindowsFileStore.create() throws an IOException here, it is caught and the FileStore is skipped and omitted from the iteration. Perhaps something similar to what is done on Windows needs to be done on Unix. Using access(2) for this purpose is one option, but it will hang if the NFS server for a mount point if it becomes unreachable between when the mount point entries are obtained and when the access() function is invoked.

Looks like a transient issue on this system: /tmp/common1 (rwsnas429:/export/local) (name=rwsnas429:/export/local type=nfs)