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.

Bug 46813

Summary: NetBeans does not support UNC paths
Product: platform Reporter: gaucho72 <gaucho72>
Component: FilesystemsAssignee: Jiri Skrivanek <jskrivanek>
Status: RESOLVED FIXED    
Severity: blocker CC: anebuzelsky, clheiny, dkonecny, err, ieising, issues, jchalupa, jglick, jtulach, misterm, mkrauskopf, mmirilovic, pjiricka, tboudreau, ttran
Priority: P1 Keywords: PLAN, REGRESSION, RELNOTE
Version: 4.x   
Hardware: PC   
OS: Windows XP   
URL: http://wiki.netbeans.org/FaqUNCPaths
Issue Type: ENHANCEMENT Exception Reporter:
Bug Depends on: 141092, 146948, 213562    
Bug Blocks: 47178, 50058, 55445    
Attachments: UNC enabled IDE patch.

Description gaucho72 2004-08-01 09:31:08 UTC
Referring to issues 46630 and 46706 which are 
closed as fixed.

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 suggested in issue 
46630.

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 I set prio to P1.
Comment 1 rmatous 2004-08-02 09:59:49 UTC
There is possible to access files from remote hosts but there isn't
possible to use Windows feature "Make available offline". I know that
there are some people that use it but I think that using of e.g. cvs
is much more common.


Even in NB 3.6 I never intended to support mentioned feature and I'm
almost sure nobody tested it and nowhere was mentioned that something
like that should work. If it worked fine that it was just a sort of a
luck. 

 
UNC names like \\saaaf004\homes\olscha2\My Documents are and won't be
supported in promo-D (MasterFileSystem doesn't support such names). I
have no reason to block this sort of functionality. So, I change it to
RFE and I will consider it for promo-E. 

Comment 2 Jesse Glick 2004-08-02 13:00:18 UTC
The difference being that in 3.6 you could explicitly mount whatever
root dir you wanted and it would not play any tricks with that path
prefix. Use of masterfs has made the Filesystems API more vulnerable
to platform-specific oddnesses near disk roots, it seems. IMHO a
defect, not an enhancement.
Comment 3 rmatous 2004-08-02 14:41:48 UTC
gaucho72: why you can't map network drives for "making available
offline". I tested it and it works fine for me.

jesse: To be correct there must be said that its more vulnerable just
in case  if there is used file protocol for accessing hosts and
network drives. On Windows its near disk root (mapped network drives
and UNC drives completely outside of disk hierarchy that should be
probably mounted virtually under the root). On Linux somewhere else
e.g. net folder. 


AFAIK "Make available offline" on Windows (moereover it works for me
even on mapped network drives) is the only known use case. Although
feasible I'm still not sure if it deserves P1 DEFECT category for this
issue. 

OK I'll play with it and if I have feeling that fix is relatively safe
and without negative affection of performance then I'll strive to fix
it even for promo-D but I can't promise it without deeper
investigation. (Possible perf.problem: MasterFS is often refreshed
then its hard referenced root is refreshed - then all its UNC
refrenced children must be rechecked etc. ). 

Comment 4 Jesse Glick 2004-08-02 16:53:05 UTC
Didn't suggest P1 DEFECT, just some level of DEFECT - the drive paths
are perfectly legitimate Windows folders, and java.io.File supports
them (somehow), presumably other apps support them, yet NB does not.
Comment 5 gaucho72 2004-08-03 10:46:01 UTC
Radek, you're right, sorry for being such a dummy windows user. Of 
course, I can map this folder to some drive letter. Nevertheless, 
the 'My Documents'-folder is normally the first option you can see at 
the open dialog. And it's hard to communicate this to a NB user that 
the behaviour he knows from ohter win-apps isn't available in 
netbeans.
Comment 6 Jesse Glick 2004-08-03 16:18:31 UTC
Is it even widely known among Windows users that you can map drive
letters?
Comment 7 rmatous 2004-08-03 17:26:22 UTC
I think that its the same like using UNC path directly (already used
on DOS). Typicaly file managers on Windows shows you maped drives and
let you map new ones or from command line "net" command. And once
maped drive can survive restart if requested.

Typical usage is either map such drive or create shortcut (somethink
like   link) for UNC path. Then you must choose such files from
FileChooser either by clicking on ComboBox for map drive or findng
shortcut on your disk and follow it. In other words you wrap your UNC
path into either some virtual maped drive or virtual folder (called
shortcut).
Comment 8 rmatous 2004-08-03 18:04:09 UTC
Maped drives can be listed by File.listFiles (). 

Direct support for UNC path means create them dynamically
(automount)and introduce some virtual files because  
for new File(\\saaaf004).exists == false although new File
(\\saaaf004\homes).exists == true or create one FileOject with merged
path e.g. saaaf004-homes and somehow translate names. 

Simpler and much more safe variant could be to put the logic into
MasterURLMapper and simply create LocalFileSystem as it was in NB3.6
for UNC and provide FileObject from it (similar to ArchiveURLMapper
bahaviour) - hardly to support cvs.
Comment 9 rmatous 2004-08-10 09:56:18 UTC
FYI I wanted to know if IDEA or Eclipse support UNC names and let you
use it e.g. as reference for source path in project settings.

AFAIK Eclipse supports it and IDEA doesn't.
Comment 10 gaucho72 2004-08-10 12:48:31 UTC
Eclipse 3.0 does, I've tested it today.
Comment 11 rmatous 2004-08-12 17:10:15 UTC
There are important bugs reported against UNC path impl. in JDK. These
could affect us: 
- 4723726 URI.normalize () ruins URI builf from UNC file
- 4241259 java.io.File.getParentFile () return non directory
- 5086147 File,URI,URL conversions are strange for UNC path


I don't recommend to implement this RFE until these issues are fixed
because workarounds would spread accros the code not just fs
implementation (moreover endless parsing for recognizing UNC would
take time). 
Comment 12 Petr Jiricka 2004-09-13 17:25:27 UTC
> Is it even widely known among Windows users that you can map drive
> letters?

This issue is somewhat related to issue 45690 about adding network
drive roots to the Favorites tab, in the sense that even if you know
how to map a drive letter on Windows, it may not help you.
Comment 13 Jesse Glick 2005-01-16 17:12:04 UTC
*** Issue 53468 has been marked as a duplicate of this issue. ***
Comment 14 rmatous 2005-02-24 09:37:45 UTC
FileBasedFileSystem should be ready for UNC path including all those
JDK workarouns and was designed to replace MasterFS at all. But there
are other two problems now. First these workarounds must be spread
across all the code - on all places where there is used File,URL,URI
conversion. The second problem is that we can't exclude
MasterFileSystem yet and easily replace it by FileBasedFileSystem
because we still need to support VCS. MasterFileSystem only delegates
on FileBasedFileSystem but MasterFileSystem isn't ready for UNC path
because MasterFS developed gradually and original use cases was
radically distinct from what we expect and nobody didn't consider UNC
at all.    Both problems shouldn't be so tough to solve but vulnerable
to serious bugs and then risky.       
Comment 15 Jesse Glick 2005-05-05 22:11:39 UTC
*** Issue 58623 has been marked as a duplicate of this issue. ***
Comment 16 Jesse Glick 2005-05-30 14:42:23 UTC
*** Issue 59200 has been marked as a duplicate of this issue. ***
Comment 17 Jesse Glick 2005-05-30 14:44:17 UTC
Continue to suggest DEFECT status for this item; really a problem. Is there any
plan for addressing this?
Comment 18 rmatous 2005-05-30 15:18:57 UTC
I still thing that issue is more RFE than DEFECT. On the other hand I'd really
like to fix it for 4.2. 
Comment 19 Marian Mirilovic 2005-06-09 10:43:19 UTC
*** Issue 59761 has been marked as a duplicate of this issue. ***
Comment 20 Marian Mirilovic 2005-06-09 10:44:31 UTC
*** Issue 59700 has been marked as a duplicate of this issue. ***
Comment 21 Marian Mirilovic 2005-06-09 10:46:06 UTC
*** Issue 59534 has been marked as a duplicate of this issue. ***
Comment 22 Jesse Glick 2005-06-17 12:20:10 UTC
*** Issue 60091 has been marked as a duplicate of this issue. ***
Comment 23 Jesse Glick 2005-06-17 12:21:15 UTC
I think this needs to be treated as a DEFECT (probably P2) and planned for as such.
Comment 24 Jesse Glick 2005-07-21 17:16:53 UTC
*** Issue 61214 has been marked as a duplicate of this issue. ***
Comment 25 Jesse Glick 2005-09-13 22:49:31 UTC
*** Issue 64247 has been marked as a duplicate of this issue. ***
Comment 26 Jesse Glick 2005-09-14 18:24:08 UTC
*** Issue 64213 has been marked as a duplicate of this issue. ***
Comment 27 Tomas Zezula 2005-09-14 18:51:06 UTC
*** Issue 58714 has been marked as a duplicate of this issue. ***
Comment 28 Tomas Zezula 2005-09-19 14:25:18 UTC
*** Issue 64586 has been marked as a duplicate of this issue. ***
Comment 29 rmatous 2005-09-22 17:09:11 UTC
*** Issue 58587 has been marked as a duplicate of this issue. ***
Comment 30 Jan Chalupa 2005-10-04 20:15:32 UTC
*** Issue 65894 has been marked as a duplicate of this issue. ***
Comment 31 rmatous 2005-10-05 11:08:15 UTC
*** Issue 65894 has been marked as a duplicate of this issue. ***
Comment 32 rmatous 2005-10-11 11:45:25 UTC
*** Issue 61496 has been marked as a duplicate of this issue. ***
Comment 33 rmatous 2005-10-11 11:46:15 UTC
*** Issue 63132 has been marked as a duplicate of this issue. ***
Comment 34 waynezhang 2005-11-25 03:46:35 UTC
*** Issue 63132 has been marked as a duplicate of this issue. ***
Comment 35 Jesse Glick 2005-12-06 16:01:56 UTC
Giving this a better summary.

Idea for a workaround which would not touch masterfs and would not rely on any
JDK URL fixes: adjust FileUtil.normalizeFile on Windows to:

1. Check for UNC syntax (path.startsWith("\\\\")). If not UNC, exit (continue to
existing normalization logic).

2. Run (Runtime.exec) "net use" to list current drive mappings. (Cache result
for future use.) If there is a mapping for the current path, rewrite to that
drive, then continue to existing normalization logic.

3. Run "net use * \\host\share /persistent:yes" (I think?).

4. Rerun step #2 (rebuilding cache since it should have changed). If it does not
work this time, fail.

Not ideal but better than not working at all, IMHO, and potentially a pretty
simple and isolated fix. FU.nF is used by both the startup code which handles
${netbeans.user}, and all code which accepts paths from filechoosers (including
FileUtil.toFileObject).
Comment 36 _ tboudreau 2005-12-09 20:22:55 UTC
In the meantime, wouldn't it be pretty easy to intercept someone trying to open a project w/ UNC name 
and pop up a dlg telling them to map the drive (i.e. if file.getPath().startsWith ("\\\") && 
Utilities.isWindows()...)?
Comment 37 rmatous 2005-12-10 14:06:28 UTC
*** Issue 70057 has been marked as a duplicate of this issue. ***
Comment 38 Jesse Glick 2005-12-10 20:45:30 UTC
Re. Tim's last comment - I don't know where you would put such interception
logic, exactly; perhaps in the Open Project dialog. (Would prefer a fix purely
in the filesystems layer, since that is where the bug is.) But that's only one
of a number of problems; there are other places you can introduce UNC paths from
the IDE (e.g. when adding a library)... and one of the most common problems
seems to be people trying to run with a UNC userdir, which is a problem before
the GUI even appears, and can't be cancelled.
Comment 39 Jan Chalupa 2005-12-11 12:58:07 UTC
Re: "run 'net use'". I don't like it. 'net use' is a system wide command on
Windows. The IDE would be silently mapping network drives to letters and
probably leaving them around after the user exits the IDE. I cannot think of any
other Windows app doing something like that.

Would the same mechanism be used for storing absolute paths to specific
resources (e.g. libraries)? I don't think we can realistically expect users to
preserve the drive mappings created by the IDE and then they would repeatedly
end up with broken references.

I would prefer a solution with a descriptive error message providing the user
with instructions on what to do to work around the problem (map the UNC path to
a drive manually). Mapping the drives automatically would be too aggressive, IMO.
Comment 40 Milan Kubec 2005-12-20 15:05:10 UTC
*** Issue 57886 has been marked as a duplicate of this issue. ***
Comment 41 Jesse Glick 2005-12-23 15:00:45 UTC
*** Issue 70768 has been marked as a duplicate of this issue. ***
Comment 42 Marian Mirilovic 2006-01-10 12:53:39 UTC
I think it has to be mentioned in Release notes for NB 5.0, hasn't it ?
Comment 43 Marian Mirilovic 2006-01-11 11:16:34 UTC
*** Issue 71251 has been marked as a duplicate of this issue. ***
Comment 44 Marian Mirilovic 2006-01-11 11:18:22 UTC
Comments from issue 71227 :
-----------------
[ BUILD # : 200601052030 ]
[ JDK VERSION : 1.5.0_06 ]

Hi,

I know this is an issue already brought up by me, but I feel that since it is
known that NB can't handle this, it would be better for NB's image to provide
the user with a message what is going on, what the implications are and how
(s)he can solve this. This because it came up here at a clients, after me
telling one of the co-developers how cool NB is and he started to laugh since
the first thing after the admittedly cool splash was an exception.

Now the user is even provided with that this is a known issue, but no assurance
about that there are no implications, nor how to solve this.
Also note, that although NB can't handle this, when I want to open a project, NB
starts in the UNC, so I don't get the point in throwing this exception, since to
me it doesn't seem to be an issue at all. Sofar no problems were faced even with
the userdir on a UNC path.

Iwan
Comment 45 Marian Mirilovic 2006-01-11 11:19:16 UTC
*** Issue 71227 has been marked as a duplicate of this issue. ***
Comment 46 Marian Mirilovic 2006-01-19 08:54:17 UTC
*** Issue 71565 has been marked as a duplicate of this issue. ***
Comment 47 Marian Mirilovic 2006-01-20 10:00:06 UTC
*** Issue 71604 has been marked as a duplicate of this issue. ***
Comment 48 Marian Mirilovic 2006-01-20 10:27:14 UTC
*** Issue 63132 has been marked as a duplicate of this issue. ***
Comment 49 Marian Mirilovic 2006-01-20 10:28:01 UTC
*** Issue 71644 has been marked as a duplicate of this issue. ***
Comment 50 Jesse Glick 2006-02-08 23:56:17 UTC
*** Issue 72360 has been marked as a duplicate of this issue. ***
Comment 51 Tomas Zezula 2006-02-24 14:06:20 UTC
*** Issue 72636 has been marked as a duplicate of this issue. ***
Comment 52 Jan Lahoda 2006-03-07 13:55:19 UTC
*** Issue 73333 has been marked as a duplicate of this issue. ***
Comment 53 leouk 2006-03-16 09:01:43 UTC
Hi,

I suffer exactly the same problem as mentioned by
the first comment in this issue by rmatous.

I think a possible way around it would be to set the 
Home dir that Netbeans fetches. In the Configuration
(and Preformance) FAQ's, it is clear that the ability
to change "userdir" in the etc/netbeans.conf file 
is very handy for this very problem.

Wouldn't it be possible to allow something similar
for the Home dir as well?!



I tried going around it by se
Comment 54 Jan Chalupa 2006-03-16 09:05:57 UTC
Not sure what you tried (truncated), but you should be able to set your home dir
like this:

  -J-Duser.home=<some-non-unc-path>

And if it works, add the option to etc/netbeans.conf file.
Comment 55 Marian Mirilovic 2006-04-18 18:13:06 UTC
*** Issue 71677 has been marked as a duplicate of this issue. ***
Comment 56 Milan Kubec 2006-05-04 12:10:29 UTC
*** Issue 75477 has been marked as a duplicate of this issue. ***
Comment 57 Jesse Glick 2006-05-05 15:37:24 UTC
*** Issue 71625 has been marked as a duplicate of this issue. ***
Comment 58 Jesse Glick 2006-06-14 14:49:28 UTC
*** Issue 77878 has been marked as a duplicate of this issue. ***
Comment 59 rmatous 2006-09-15 14:49:40 UTC
*** Issue 81895 has been marked as a duplicate of this issue. ***
Comment 60 Jesse Glick 2006-11-08 17:06:48 UTC
*** Issue 88745 has been marked as a duplicate of this issue. ***
Comment 61 Jesse Glick 2006-11-08 18:31:36 UTC
*** Issue 88745 has been marked as a duplicate of this issue. ***
Comment 62 Jesse Glick 2006-11-21 18:18:28 UTC
*** Issue 89715 has been marked as a duplicate of this issue. ***
Comment 63 Jesse Glick 2007-03-07 09:59:29 UTC
*** Issue 97345 has been marked as a duplicate of this issue. ***
Comment 64 Tomas Zezula 2007-10-29 15:52:56 UTC
*** Issue 98836 has been marked as a duplicate of this issue. ***
Comment 65 misterm 2007-11-09 19:30:34 UTC
Shouldn't this be changed to DEFECT?
Comment 66 David Vancouvering 2007-11-10 04:21:28 UTC
*** Issue 119883 has been marked as a duplicate of this issue. ***
Comment 67 Tomas Zezula 2007-12-04 16:50:11 UTC
*** Issue 122799 has been marked as a duplicate of this issue. ***
Comment 68 schmidtm 2007-12-14 11:22:27 UTC
*** Issue 124016 has been marked as a duplicate of this issue. ***
Comment 69 rmatous 2008-01-14 19:22:16 UTC
*** Issue 124985 has been marked as a duplicate of this issue. ***
Comment 70 Tomas Zezula 2008-01-15 03:32:58 UTC
*** Issue 114984 has been marked as a duplicate of this issue. ***
Comment 71 Sonali Kochar 2008-01-24 18:29:59 UTC
*** Issue 124651 has been marked as a duplicate of this issue. ***
Comment 72 Lukas Jungmann 2008-03-12 16:44:16 UTC
*** Issue 114370 has been marked as a duplicate of this issue. ***
Comment 73 Jiri Skrivanek 2008-05-28 14:52:35 UTC
I have a patch which enables to use IDE with userdir and projects on UNC paths. As mentioned in one of previous comments
there are still JDK issue which we have to workaround

- 4723726 URI.normalize () ruins URI builf from UNC file
   - workarounded in particular modules
- 4241259 java.io.File.getParentFile () return non directory
   - workarounded in openide.filesystems and masterfs modules
- 5086147 File,URI,URL conversions are strange for UNC path
   - fixed in JDK1.6 but for JDK1.5 workarounded in o.n.bootstrap

The patch doesn't break current functionality, so I want to integrate it soon for testing.
Comment 74 Jiri Skrivanek 2008-05-28 14:53:18 UTC
Created attachment 62063 [details]
UNC enabled IDE patch.
Comment 75 Jesse Glick 2008-05-28 15:58:51 UTC
See my comments to 4723726. Rather than avoiding URI.normalize(), which AFAICT is behaving correctly, we could instead
consider adding custom versions of File.toURI and new File(URI) to FileUtil which behave correctly with UNC paths (i.e.
use "file://server/path" rather than "file:////server/path"); when the JRE bug is fixed we could deprecate the special
methods. Just a suggestion; I'm not sure how disruptive this would be to our codebase.
Comment 76 Jesse Glick 2008-05-28 19:12:37 UTC
I guess forget about my last comment. Apparently the behavior of File.toURI will never be changed:

"It's in the spec that the authority is undefined (meaning not present). What's worse it that we often come across code
that uses the path component as file name. We can't change behavior that would cause existing code to break (even if
that code is bad)."

The NIO.2 APIs (http://jcp.org/en/jsr/detail?id=203) may do better here; I know a backport to JDK 6 is planned (not sure
about JDK 5).
Comment 77 Jiri Skrivanek 2008-05-28 21:07:31 UTC
I see possible problems in baseURI.resolve(relativeURI). URI.resolve() method calls URI.normalize() and returns
"file:/server/path". Then resulting File is invalid. I am afraid we can't anyhow hack URI.resolve() method. Maybe we can
create FileUtil.resolve(baseURI, relativeURI).

> The NIO.2 APIs (http://jcp.org/en/jsr/detail?id=203) may do better here;

Could you be more specific what the change will be?
Comment 78 Jesse Glick 2008-05-28 21:44:07 UTC
Regarding resolve vs. normalize: I am still a bit uncomfortable with this. The URI class is correct as it is. We are
just dealing with incorrect URIs. Creating URI FileUtil.toURI(File) and File FileUtil.toFile(URI) would be more correct.
On the other hand, we have a lot more usages of File.toURI and File.<init>(URI) then we do of URI.resolve and
URI.normalize, so doing it "right" would be a bigger source change (probably requiring Jackpot).

Regarding NIO.2:

http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html#get(java.net.URI)
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/Path.html#toUri()

The correct conversions are done in src/windows/classes/sun/nio/fs/WindowsUriSupport.java (which also handles IPv6,
Unicode host names, and other exotica).
Comment 79 Jiri Skrivanek 2008-05-29 10:11:21 UTC
OK, I see your concern. So far, I think the best solution is to avoid resolve and normalize.
Comment 80 Jiri Skrivanek 2008-06-02 07:47:48 UTC
I integrated proposed patch together with additional workarounds for JDK issues. Now Netbeans IDE handles UNC paths on
JDK1.5 and JDK1.6. Please, let me know whenever you encounter some issue with it.

http://hg.netbeans.org/core-main/rev/4f31df7b30bb
Comment 81 Quality Engineering 2008-06-03 04:09:03 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #234 build
Changeset: http://hg.netbeans.org/main/rev/4f31df7b30bb
User: Jiri Skrivanek <jskrivanek@netbeans.org>
Log: #46813 - support for UNC paths in NetBeans.
Comment 82 Jiri Skrivanek 2008-06-05 09:04:54 UTC
*** Issue 136467 has been marked as a duplicate of this issue. ***
Comment 83 Lukas Hasik 2008-07-01 10:06:57 UTC
this issue was tested 
-nb installed on and started from UNC path
-nb userdir on UNC path
-jdkhome on UNC path
-create/open project on UNC path
Comment 84 Jesse Glick 2008-07-17 20:29:16 UTC
Resetting Version field to original value. Please do not change.
Comment 85 David Konecny 2008-07-21 23:29:16 UTC
I just discovered that this change broke
project.libraries/src/org/netbeans/spi/project/libraries/support/LibrariesSupport.java. You replaced
"libBase.toURI().resolve(libraryEntry)" with code which appends libraryEntry to libBase but in case libraryEntry is
relative the resulting URI is 

  jar:file:/lib/base/path/../../relative/library/entry/path.jar!/

instead of expected

  jar:file:/lib/relative/library/entry/path.jar!/

The result is for example that Show Javadoc or Go to Source does not work for sharable libraries with Javadoc/sources 
defined as relative paths.

I'm going to have a look at how to workaround it in this instance but consider reviewing your diff as the same problem
could happen in other places. If URI.normalize/resolve is buggy then best would be to write your own normalize method in
(eg.) FileUtils and use it instead.
Comment 86 Jesse Glick 2008-07-22 00:15:57 UTC
To LibrariesSupport being broken - please file a new DEFECT blocking this one, and please write a unit test for the
desired behavior - this project's tests are being run constantly (in core-main), which could have detected the problem
much earlier.
Comment 87 David Konecny 2008-07-22 01:31:18 UTC
There are tests but none of them is testing scenario of path starting with "../". I have a fix and a test for issue 141092.
Comment 88 Jiri Skrivanek 2008-09-04 10:17:34 UTC
*** Issue 134396 has been marked as a duplicate of this issue. ***
Comment 89 Jesse Glick 2012-05-24 11:52:37 UTC
I expanded the platform-unc job mentioned in bug #207060 comment #18 to run the same module list as NB-Core-Build.
Comment 90 Jesse Glick 2012-06-01 13:50:04 UTC
The growing list of blocking bugs shows that this is not fixed at all, and it does not take much work to reproduce plenty more exceptions. As mentioned in comment #78, the problem plaguing the current codebase is that we rely on File.toURI and new File(URI), which are wrong and should be considered deprecated. We need a single pair of well-tested replacement methods, probably in openide.util so they can be used even by the module system, which would delegate to NIO.2 in JDK 7 and manually handle UNC in JDK 6; and then some Jackpot hints to replace current usages, to be applied en masse to our codebase.
Comment 91 Jaroslav Tulach 2012-06-03 19:19:22 UTC
(In reply to comment #90)
> The growing list of blocking bugs shows that this is not fixed at all, 

This bug was indeed fixed, but...

> comment #78, the problem plaguing the current codebase is that we rely on
> File.toURI and new File(URI), 

...since recent releases (7.0?) you (!) started to use URI more often (see FileObject.toURI). And now the NetBeans is completely broken when used with UNC.

> We need a single pair of well-tested replacement methods,

I am not sure why it is not better to revert back to the original state when Jirka made UNC work but I am sure you will have tons of arguments in favor of spreading broken URI all over which I will not be able to absorb.
Comment 92 Jaroslav Tulach 2012-06-04 09:45:42 UTC
Marking fixed, as this was fixed in 6.5. Assigning back to Jirka, as the one who made the fix in 6.5.

Reopening a general issue like this without mentioning how to reproduce the problem is insane. Create new issue(s) that will say something like "NetBeans IDE does not support UNC since it started to use URI heavily" and mention the individual errors your are facing.