Observation Investigation [1] provided with the issue is quite comprehensive. It was easy for me to reproduce the behaviour. The message of the exception being swallowed (author mentioned this) is this: java.nio.file.FileSystemException: y:\temp: The directory is not a subdirectory of the root directory. Originally it was thrown from the call to sun.nio.fs.WindowsNativeDispatcher.GetVolumeInformation(String root) According to [2] GetVolumeInformation that is wrapped by the method above expects a "string that contains the root directory of the volume to be described". 'y:\temp' indeed is not a root directory of volume 'y:'. But this value was returned by GetVolumePathName when called with 'y:\temp\temp'. Though documentation [2] mentions symlink behaviour it doesn't mention 'substed' drives behaviour. I tried different scenarios [A] to see how it works: path root=GetVolumePathName(path) GetVolumeInformation(root) ---------------------------------------------------------------------------- c: C:\ NTFS, System, -533035421 c:/ c:\ NTFS, System, -533035421 c:/temp c:\ NTFS, System, -533035421 c:/temp/temp c:\ NTFS, System, -533035421 c:/vhd1 c:\vhd1\ NTFS, New Volume, 369829843 c:/vhd1/temp c:\vhd1\ NTFS, New Volume, 369829843 c:/vhd1/vhd2 c:\vhd1\vhd2\ NTFS, New Volume, 1781250352 c:/vhd1/vhd2/temp c:\vhd1\vhd2\ NTFS, New Volume, 1781250352 c:/symlink C:\ NTFS, System, -533035421 c:/symlink/temp C:\ NTFS, System, -533035421 c:/junction c:\ NTFS, System, -533035421 c:/junction/temp c:\ NTFS, System, -533035421 y: The parameter is incorrect. y:/ The parameter is incorrect. y:/temp y:\temp\ The directory is not a subdirectory of the root directory. As per table it's either the root directory cannot be retrieved and exception is thrown or the volume information for the retrieved root cannot be obtained. In the last line it's expected for GetVolumePathName to return "y:\", but "y:\temp" returned instead. Unfortunately I wasn't able to find any clarifications on this whatsoever except for several mentions of similar behaviour on internet forums (e.g. [3]). It seems to me that GetVolumePathName doesn't support 'substed' drives. I experimented a little bit with Volume Management Functions [4] and I think there is another way of getting VolumeInformation even for 'substed' drives. It turns out we don't have to get a root directory of the volume to get its volume information. Instead we can use following approach (schematically): handle = CreateFile(path) volumeInformation = GetVolumeInformationByHandleW(handle) CloseHandle(handle) Here's the result of initial run of the prototype: path GetVolumeInformation(GetVolumePathName(path)) GetVolumeInformationByHandleW ------------------------------------------------------------------------------------------------- c: NTFS, System, -533035421 NTFS, System, -533035421 c:/ NTFS, System, -533035421 NTFS, System, -533035421 c:/temp NTFS, System, -533035421 NTFS, System, -533035421 c:/temp/temp NTFS, System, -533035421 NTFS, System, -533035421 c:/vhd1 NTFS, New Volume, 369829843 NTFS, New Volume, 369829843 c:/vhd1/temp NTFS, New Volume, 369829843 NTFS, New Volume, 369829843 c:/vhd1/vhd2 NTFS, New Volume, 1781250352 NTFS, New Volume, 1781250352 c:/vhd1/vhd2/temp NTFS, New Volume, 1781250352 NTFS, New Volume, 1781250352 c:/symlink NTFS, System, -533035421 NTFS, System, -533035421 c:/symlink/temp NTFS, System, -533035421 NTFS, System, -533035421 c:/junction NTFS, System, -533035421 NTFS, System, -533035421 c:/junction/temp NTFS, System, -533035421 NTFS, System, -533035421 y: NTFS, System, -533035421 y:/ NTFS, System, -533035421 y:/temp The directory is not a subdirectory of... NTFS, System, -533035421 So the rightmost column contains valid volume information for each path from the leftmost column. It looks like GetVolumeInformationByHandleW offers a more general way. So we don't need root directory to get the volume information. Compatibility and design implications. Even without the need to retrieve volume information through the root the current implementation still needs the root directory. Here are all usages: 1. WindowsFileStore.WindowsFileStore (GetDriveType(root)) 2. WindowsFileStore.readDiskFreeSpace (GetDiskFreeSpaceEx(root)) 3. WindowsFileStore.rethrowAsIOException 4. WindowsFileStore.equals 5. WindowsFileStore.hashCode 6. WindowsFileStore.toString The good thing 'root' is confined in the class. The value never escapes it. (Except for a toString output / WindowsException message that can be parsed, but as far as I can see neither of them is following any specific contract on the format of the string so anyone who is using it should know it can change). For the following usages need root: WindowsFileStore.rethrowAsIOException WindowsFileStore.equals WindowsFileStore.hashCode WindowsFileStore.toString For all the purposes above we can probably use volume serial number which is available as a part of the volume information. The bad thing is that WindowsFileStore.WindowsFileStore (GetDriveType(root)) needs root directory as an argument and this WindowsFileStore.readDiskFreeSpace (GetDiskFreeSpaceEx(root)) needs any folder on the volume (not necessarily a root). I tried an experiment with raw path and got this: path GetDriveType(path) GetDiskFreeSpace(path) ----------------------------------------------------------------------- c: 3 251483930624, 350072336384,... c:/ 3 251483930624, 350072336384,... c:/temp 1 251483930624, 350072336384,... c:/temp/temp 1 251483930624, 350072336384,... c:/vhd1 1 3493888, 7335936, 3493888 c:/vhd1/temp 1 3493888, 7335936, 3493888 c:/vhd1/vhd2 1 7618560, 17821696, 7618560 c:/vhd1/vhd2/temp 1 7618560, 17821696, 7618560 c:/symlink 1 251483930624, 350072336384,... c:/symlink/temp 1 251483930624, 350072336384,... c:/junction 1 251483930624, 350072336384,... c:/junction/temp 1 251483930624, 350072336384,... y: 3 251483930624, 350072336384,... y:/ 3 251483930624, 350072336384,... y:/temp 1 251483930624, 350072336384,... GetDriveType 1 means [5] "DRIVE_NO_ROOT_DIR: The root path is invalid". It doesn't seem that drive type is heavily used, and looks like we don't rely on it in this particular class. So can we simply leave it "as is"? As for GetDiskFreeSpace we need to obtain any directory on the same volume the initial path points to. How to do this? I don't have a solution by now. Any solution that comes to mind seems ad-hoc or hacky. Passing simply a path may not work (as expected): path GetDriveType(path) GetDiskFreeSpace(path) --------------------------------------------------------------------------- c:/temp/temp/text.txt 1 The directory name is invalid. Performance implications. Initial measurements done by jmh showed performance overhead of obtaining the volume information of approx. 25% But I guess the overall performance degradation depends on a particular scenario (e.g. how often WindowsFileStore is created). Conclusion 'subst' itself is an old command, but it delivers some functionality that is absent in 'mklink'. So I don't think we should think of it as of legacy and therefore it should be considered when designing implementation of WindowsFileStore. References [1] http://mail.openjdk.java.net/pipermail/nio-discuss/2014-February/000717.html [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx [3] http://www.experts-exchange.com/Programming/Languages/CPP/Q_24142140.html#a23657759 [4] http://msdn.microsoft.com/en-us/library/windows/desktop/aa365730(v=vs.85).aspx [5] http://msdn.microsoft.com/en-us/library/windows/desktop/aa364939(v=vs.85).aspx [A] The configuration is this: vhd1, vhd2 -- are virtual hard drivers created with 'diskmgmt.msc' and mounted to the 'c:/vhd1' and 'c:/vhd1/vhd2' accordingly. 'c:/symlink' and 'c:/junction' are the symbolic links and directory junction created with 'mklink /D' and 'mklink /J' accordingly. 'y:' is a subst drive: c:\>dir Volume in drive C is System Volume Serial Number is E03A-8663 Directory of c:\ 04/17/2014 10:00 AM junction [c:\temp] ... 04/17/2014 09:59 AM symlink [c:\temp] ... 04/17/2014 09:56 AM vhd1 [\??\Volume{37e143ea-c4b1-11e3-ad12-b86b2309670f}\] ... c:\vhd1>dir Volume in drive C is System Volume Serial Number is E03A-8663 Directory of c:\vhd1 ... 04/17/2014 09:57 AM vhd2 [\??\Volume{37e1443b-c4b1-11e3-ad12-b86b2309670f}\] ... c:\>subst Y:\: => C:\temp [B] It's different in WindowsFileSystem and WindowsPath where both root and drive type are also used. But it looks like the root in this class is obtained so to say in a "soft way" -- through the WindowsPathParser rather than through win32 calls.