java.nio.file.Path error with VSS (Volume Shadow Copy) paths

Question

Using VSS, I've created a volume snapshot and can successfully access files on it:

C:\> type \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Eric\Desktop\test.txt
test text 1/2
test text 2/2

When I try to access the same file from java using java.io.File it works fine. However I am unable to convert it to a java.nio.file.Path by calling toPath like this:

File file = newFile(vssPath)
Path path = file.toPath()

Doing so results in an exception trace. This is a known issue for OpenJDK and I get the same result with java 1.8.91:

STACKTRACE:: java.nio.file.InvalidPathException: Illegal character [?] in path at index 2: \\?    \GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\qa\Desktop\lock_full.txt
    at sun.nio.fs.WindowsPathParser.nextSlash(Unknown Source)
    at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
    at sun.nio.fs.WindowsPathParser.parse(Unknown Source)
    at sun.nio.fs.WindowsPath.parse(Unknown Source)
    at sun.nio.fs.WindowsFileSystem.getPath(Unknown Source)
    at java.io.File.toPath(Unknown Source)

Since I can't get a Path there are certain APIs I'm unable to use, for example java.nio.channels.AsynchronousFileChannel which can only be instantiated with a Path.

Is there any alternative syntax for accessing the shadow copy file that won't run afoul of this JDK limitation? The OpenJDK ticket linked above recommends just omitting the long-UNC prefix (\\?) but I haven't found any variation of this that seems to be legal. For example the following all fail:

    C:\> type \\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Users\Eric\Desktop\test.txt
    C:\> type \\Device\HarddiskVolumeShadowCopy1\Users\Eric\Desktop\test.txt
    C:\> type \\HarddiskVolumeShadowCopy1\Users\Eric\Desktop\test.txt

If there's no variant path I can use to call toPath() then is there some other way I could acquire a java.nio.file.Path that doesn't run afoul of the parser limitation?

I think that Alan is saying that dropping the prefix might work *in Java*. It certainly won't work from the command line. (The idea appears to be that Java will automatically put the prefix back when calling the Windows API. Although I don't quite understand how it can tell when that's the right thing to do.) — Harry Johnston, Dec 01 '16 at 22:35
Perhaps java will correctly add the prefix when required because the length of the path is greater than MAX_PATH? That would make sense but of course doesn't help for working with VSS. — Eric, Dec 01 '16 at 23:01
I considered that, but the OP at the linked ticket said that it solved their problem, and they didn't *seem* to be dealing with long paths. Hard to be certain though. — Harry Johnston, Dec 01 '16 at 23:12

score 0 · Answer 1 · answered Dec 02 '16 at 17:39

In the absence of a timely workaround, my team discussed:

create our own implementation of java.nio.file.Path (or find one in some other library)
change code to avoid the use of java.nio.file.Path

... and we settled on #2. #1 would be a more general workaround should probably be the accepted answer if somebody ever does it and shares.

java.nio.file.Path error with VSS (Volume Shadow Copy) paths

1 Answers1