Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

getCanonicalPath error on Windows CD drive

4 views
Skip to first unread message

Composer

unread,
Jun 26, 2006, 2:27:20 PM6/26/06
to
My backup program is intended to work on both Apple OS X and Windows.
It happily reads and writes files on both systems, except when writing
to the CD drive on the Windows system. When I use getCanonicalPath,
the message from IOException is:

The parameter is incorrect

Perhaps this is because the CD which I'm writing to is (of course) not
yet fully initialized. But this is no problem on the Apple!

FYI it's a Dell 500m with Windows XP SP2, and the CD drive seems to be
managed by Roxio.

Ben_

unread,
Jun 26, 2006, 3:18:27 PM6/26/06
to
Hello,

I've seen the message "The parameter is incorrect" when reading burned CD's
on "regular" CD-ROM drives (ones that were not CD writer drives).

I found posts on the net telling it could have to do with burn speed.

In no way would I consider this a Java programming issue.


Oliver Wong

unread,
Jun 26, 2006, 5:02:03 PM6/26/06
to

"Composer" <comp...@uwclub.net> wrote in message
news:1151346440.9...@i40g2000cwc.googlegroups.com...

Check the stack trace. Can you tell us what method and class the exception
originates from? See
http://riters.com/JINX/index.cgi/Suggestions_20for_20Asking_20Questions_20on_20Newsgroups#RepeatErrorsExactly

- Oliver

Composer

unread,
Jun 26, 2006, 6:09:26 PM6/26/06
to
Oliver Wong wrote:
>
> Check the stack trace. Can you tell us what method and class the exception
> originates from?
>

Oliver, here is the stack trace:

java.io.IOException: The parameter is incorrect
at java.io.WinNTFileSystem.canonicalize(Native Method)
at java.io.File.getCanonicalPath(Unknown Source)
at Saver.getPrintablePath(Saver.java:243)
at Saver.copyFile(Saver.java:208)
at Saver.scanFolder(Saver.java:146)
at Saver.scanFolder(Saver.java:140)
at Saver.<init>(Saver.java:54)
at Saver.main(Saver.java:32)

I haven't yet found any documentation about java.io.WinNTFileSystem -
perhaps my ignorance is showing. But Ben, if this is not a java
programming question, what is it? I don't think this has to do with
burning, in the sense that the burn option comes up only after I've
written my files to the (as yet uncommitted) blank CD. It's java code
that works on Apple but not on Windows, but Microsoft seems unlikely to
help. Please tell me of a more relevant newsgroup. Thanks.

Composer

unread,
Jun 26, 2006, 6:19:37 PM6/26/06
to
By the way, I get the same error whether I direct my output to D:\ or
to D:\backup\

Chris Uppal

unread,
Jun 27, 2006, 6:18:36 AM6/27/06
to
Composer wrote:

> java.io.IOException: The parameter is incorrect
> at java.io.WinNTFileSystem.canonicalize(Native Method)
> at java.io.File.getCanonicalPath(Unknown Source)
> at Saver.getPrintablePath(Saver.java:243)
> at Saver.copyFile(Saver.java:208)
> at Saver.scanFolder(Saver.java:146)
> at Saver.scanFolder(Saver.java:140)
> at Saver.<init>(Saver.java:54)
> at Saver.main(Saver.java:32)
>
> I haven't yet found any documentation about java.io.WinNTFileSystem -
> perhaps my ignorance is showing.

WinNTFileSystem is part of the private platform-specific stuff which underlies
the public file system APIs in Java. There's a different version for each OS
which uses that OSes native file-related APIs.

So, what I think is happening here is that you have a Windows system (which
AFAIK doesn't know about file-systems on "blank" writable CDs), which has been
enhanced with a third-party add on. That add-on is a kernel-level custom file
system which makes a blank CD look like a writable disk. Now the Java code in
WinBTFileSystem is using the normal Win32 APIs, and is using the
Windows-specific code which it normally uses (which is primarly _fullpath()
plus FindFirstFile() and its friends -- considerably complicated by, e.g. UNC
names, and so on). But apparently that code doesn't work on your third-party
filesystem. That could be because of faulty code in the Java native
implementation, or it's because the third party file-system isn't implemented
completely correctly.

On the whole, I think it's more likely that the problem is in the custom
file-system, but I wouldn't rule out an error in either party's code -- or even
in both ;-)

But whichever is the case, I think you'll have to find some sort of workaround.
Maybe a different vendors' CD burner would work better. Perhaps your code
would work if you use UNC filenames instead of "classic" filenames (or the
other way around). Perhaps you can just code around the error.

-- chris

0 new messages