File.getCanonicalPath() throws IOException on Windows if File was constructed from URI string about jasmine-maven-plugin

[searls]

Oh no! Sorry to hear that. Are you able to share your project with me?
Or at least your directory structure and absolute path to your project
dir?

On Jul 6, 2011, at 11:14, mmajis
[email protected]
wrote:

I'm getting an IOException trying to run anything newer than 1.0.2-beta2 on Windows XP.

[INFO] The jasmine-maven-plugin encountered an exception:
java.io.IOException: The filename, directory name, or volume label syntax is incorrect
       at java.io.WinNTFileSystem.canonicalize0(Native Method)
       at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:396)
       at java.io.File.getCanonicalPath(File.java:559)
       at com.github.searls.jasmine.io.RelativizesFilePaths.relativize(RelativizesFilePaths.java:15)
       at com.github.searls.jasmine.io.scripts.RelativizesASetOfScripts.relativize(RelativizesASetOfScripts.java:17)
       at com.github.searls.jasmine.CreatesManualRunner.scriptsForRunner(CreatesManualRunner.java:43)
       at com.github.searls.jasmine.CreatesManualRunner.create(CreatesManualRunner.java:34)
       at com.github.searls.jasmine.GenerateManualRunnerMojo.run(GenerateManualRunnerMojo.java:15)
       at com.github.searls.jasmine.AbstractJasmineMojo.execute(AbstractJasmineMojo.java:193)
       ...

It seems like this is due to using ConvertsFileToUriString.convert(file) for script files and later calling the equivalent of new File(theURIString).getCanonicalPath() in RelativizesFilePaths.relativize(). If the File is constructed using a URI object, however, things seem to work: new File(new URI(theURIString)).getCanonicalPath().

Keep up the good work! :)

Reply to this email directly or view it on GitHub:
#26

[searls]

Alright, I think I figured out what's happening. The class ResolvesCompleteListOfScriptLocations.java constructs a bunch of file URIs as strings. in Windows, this will result in names like file:/c:/... which the File#getCanonicalPath() method (understandably) doesn't like.

I'll try to get this fixed ASAP since it'll probably be broken for all Windows users.

[searls]

Alright, I've committed the fixes and cut a new release to Maven central to resolve this issue. My current project now behaves as I'd expect under Windows. Please try upgrading to the new 1.0.2-beta-5 version and see if that works for you (it may take another hour or so to make its way to Central)

[searls]

^ And by "another hour or so", I mean several hours -- this is by far the longest sync time I've ever experienced :/

[mmajis]

Just successfully ran tests with 1.0.2-beta-5. Thanks for the quick fix!

[searls]

Glad to help. Thanks for creating the issue!

[mufaro23]

Hi Searls, am having the same problem on android studio can you please help me. Here is the error:

The device is not ready
java.io.IOException: The device is not ready
at java.io.WinNTFileSystem.canonicalize0(Native Method)
at java.io.WinNTFileSystem.canonicalize(WinNTFileSystem.java:404)
at java.io.File.getCanonicalPath(File.java:618)
at java.io.File.getCanonicalFile(File.java:643)
at com.android.tools.idea.stats.RunStatsService.notifyDeploySplitApkStarted(RunStatsService.kt:98)
at com.android.tools.idea.run.tasks.SplitApkDeployTask.perform(SplitApkDeployTask.java:80)
at com.android.tools.idea.run.LaunchTaskRunner.run(LaunchTaskRunner.java:121)
at com.intellij.openapi.progress.impl.CoreProgressManager$TaskRunnable.run(CoreProgressManager.java:750)
at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$1(CoreProgressManager.java:157)
at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:580)
at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:525)
at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:85)
at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:144)
at com.intellij.openapi.progress.impl.CoreProgressManager$4.run(CoreProgressManager.java:395)
at com.intellij.openapi.application.impl.ApplicationImpl$1.run(ApplicationImpl.java:305)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

[Amiya-873]

Alright, I think I figured out what's happening. The class ResolvesCompleteListOfScriptLocations.java constructs a bunch of file URIs as strings. in Windows, this will result in names like file:/c:/... which the File#getCanonicalPath() method (understandably) doesn't like.

I'll try to get this fixed ASAP since it'll probably be broken for all Windows users.

How to fix this kind of issue?