Bug 46630

Created attachment 16490 [details]
Exception that is thrown

Upgrading to P1 since exception is shown every time you go down a
directory in the file chooser dialog. Highly annoying!

Gili, please attach the log file <userdir>/var/log/messages.log

Created attachment 16491 [details]
The relevant messages.log

Added additional message. 

Revision  1.104   /cvs/openide/src/org/openide/filesystems/FileUtil.java

Please test with this revision of FileUtil and then attach log file.

I'm not able to reproduce. Messages in you log file has only
informative character and shouldn't be harmful. Then priority
decreaesed to P2.

*** Issue 45629 has been marked as a duplicate of this issue. ***

*** Issue 46706 has been marked as a duplicate of this issue. ***

JFileChooser  impl. on Windows provides
sun.awt.shell.Win32ShellFolder2. Folowing assertions are true for some
instances of Win32ShellFolder2:
Win32ShellFolder2.toURI ().getAuthority() == null;
Win32ShellFolder2.toURI ().toURL ().getAuthority() != null;

Then following call fires IllegalArgumentException because no
authority is excpected:
URI.create(Win32ShellFolder2.toURI ().toURL ().toExternalForm())

The problem occures for files with path defined according UNC (at
least I think it is so called e.g. \\saaaf004\homes\olscha2\My Documents)

Sorry, IllegalArgumentException is fired if you need to get back File:

new File (URI.create(Win32ShellFolder2.toURI ().toURL
().toExternalForm()))

In other words. The problem occures if you get Win32ShellFolder2
convert it to URL and then back to File.

Radek,

   Correct me if I'm wrong, but isn't this a JDK/specification bug?
Shouldn't this be impossible? If so, we should file a bug against JDK
5.0 immediately because as far as I can tell they are about to release
the final version.

Maybe but I think its a though thing because UNC pathes has difficult
URL interpretation with file protocol. (e.g.
\\myhost.mycompany.com\public\mylib.zip -
file:////myhost.mycompany.com/public/mylib.zip). 

Definitely current MasterFileObject isn't designed to support UNC
pathes anyway (and there isn't planned to support it ). Now there
isn't possible conversion from File to FileObject + reported exception
is fired for informative purposes. If there was urgently needed to
acces files on different hostes via our filesystems then there is
possible use UNC path and map it to regular windows drive just in
windows(e.g. Z:\). 

I think that sufficient fix is to suppres exceptions that uselessly
fill logs.

/cvs/openide/src/org/openide/filesystems/FileUtil.java,v  <--  new
revision: 1.105; previous revision: 1.104

Radek it sounds to me like a JRE bug if a URL such as

  file:////myhost.mycompany.com/public/mylib.zip

is created from File.toURI. Shouldn't it be e.g.

  file://myhost.mycompany.com/public/mylib.zip

or something along those lines?

At least, it sounds like a JRE bug if

URI.create(someFile.toURI().toURL().toExternalForm())

ever fails.

Radek, in my case \\saaaf004\homes\olscha2\My Documents is a local 
offline folder, if I'm connected to the network in our company these 
files will be syncronized with the share on the server. Unplugged I 
can use it as normal local folder (My Documents), but I can't access 
those files to map it to some drive letter, as you suggested.

So working offline I won't be able to access those files via 
Netbeans, what works well with 3.6

This is a common scenario among companies working with Windows-
Clients, so this issue isn't fixed for me.

gaucho72: your problem should probably be filed as a fresh bug, just
mention this one by number.

Guys, how is this issue "fixed"? Supressing exceptions is nice and all
but it does not fix the underlying problem. Shouldn't someone in the
Netbeans team file a JDK bug before JDK 5.0 goes final?

Gili, I file JDK bug (moreover there is definitely possible to
workaround it) but impl. of MasterFileSystem doesn't support UNC names
anyway and I don't plan to add this support for promo-D because I
don't want to destabilize MasterFileSystem code. Its stability is
relatively crucial for the whole product and I think we can live
without support for "Make available offline" functionality on Windows.

Again: a separate bug report should IMHO be filed about lack of
support for UNC names, so this can be tracked separately.

it already was

Issue #46813, specifically.

*** Issue 45882 has been marked as a duplicate of this issue. ***

*** Issue 46975 has been marked as a duplicate of this issue. ***

verified in NB 5.0