This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
dev build 200407270649 JDK 5.0 beta3-b59 fresh userdir 1) Open Project 2) Exception is thrown (attached)
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