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.
Summary: | NetBeans does not support UNC paths | ||
---|---|---|---|
Product: | platform | Reporter: | gaucho72 <gaucho72> |
Component: | Filesystems | Assignee: | 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
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. 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. 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. ). 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. 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. Is it even widely known among Windows users that you can map drive letters? 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). 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. 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. Eclipse 3.0 does, I've tested it today. 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). > 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.
*** Issue 53468 has been marked as a duplicate of this issue. *** 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. *** Issue 58623 has been marked as a duplicate of this issue. *** *** Issue 59200 has been marked as a duplicate of this issue. *** Continue to suggest DEFECT status for this item; really a problem. Is there any plan for addressing this? I still thing that issue is more RFE than DEFECT. On the other hand I'd really like to fix it for 4.2. *** Issue 59761 has been marked as a duplicate of this issue. *** *** Issue 59700 has been marked as a duplicate of this issue. *** *** Issue 59534 has been marked as a duplicate of this issue. *** *** Issue 60091 has been marked as a duplicate of this issue. *** I think this needs to be treated as a DEFECT (probably P2) and planned for as such. *** Issue 61214 has been marked as a duplicate of this issue. *** *** Issue 64247 has been marked as a duplicate of this issue. *** *** Issue 64213 has been marked as a duplicate of this issue. *** *** Issue 58714 has been marked as a duplicate of this issue. *** *** Issue 64586 has been marked as a duplicate of this issue. *** *** Issue 58587 has been marked as a duplicate of this issue. *** *** Issue 65894 has been marked as a duplicate of this issue. *** *** Issue 65894 has been marked as a duplicate of this issue. *** *** Issue 61496 has been marked as a duplicate of this issue. *** *** Issue 63132 has been marked as a duplicate of this issue. *** *** Issue 63132 has been marked as a duplicate of this issue. *** 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). 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()...)? *** Issue 70057 has been marked as a duplicate of this issue. *** 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. 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. *** Issue 57886 has been marked as a duplicate of this issue. *** *** Issue 70768 has been marked as a duplicate of this issue. *** I think it has to be mentioned in Release notes for NB 5.0, hasn't it ? *** Issue 71251 has been marked as a duplicate of this issue. *** 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 *** Issue 71227 has been marked as a duplicate of this issue. *** *** Issue 71565 has been marked as a duplicate of this issue. *** *** Issue 71604 has been marked as a duplicate of this issue. *** *** Issue 63132 has been marked as a duplicate of this issue. *** *** Issue 71644 has been marked as a duplicate of this issue. *** *** Issue 72360 has been marked as a duplicate of this issue. *** *** Issue 72636 has been marked as a duplicate of this issue. *** *** Issue 73333 has been marked as a duplicate of this issue. *** 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 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. *** Issue 71677 has been marked as a duplicate of this issue. *** *** Issue 75477 has been marked as a duplicate of this issue. *** *** Issue 71625 has been marked as a duplicate of this issue. *** *** Issue 77878 has been marked as a duplicate of this issue. *** *** Issue 81895 has been marked as a duplicate of this issue. *** *** Issue 88745 has been marked as a duplicate of this issue. *** *** Issue 88745 has been marked as a duplicate of this issue. *** *** Issue 89715 has been marked as a duplicate of this issue. *** *** Issue 97345 has been marked as a duplicate of this issue. *** *** Issue 98836 has been marked as a duplicate of this issue. *** Shouldn't this be changed to DEFECT? *** Issue 119883 has been marked as a duplicate of this issue. *** *** Issue 122799 has been marked as a duplicate of this issue. *** *** Issue 124016 has been marked as a duplicate of this issue. *** *** Issue 124985 has been marked as a duplicate of this issue. *** *** Issue 114984 has been marked as a duplicate of this issue. *** *** Issue 124651 has been marked as a duplicate of this issue. *** *** Issue 114370 has been marked as a duplicate of this issue. *** 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. Created attachment 62063 [details]
UNC enabled IDE patch.
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. 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). 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?
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). OK, I see your concern. So far, I think the best solution is to avoid resolve and normalize. 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 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. *** Issue 136467 has been marked as a duplicate of this issue. *** 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 Resetting Version field to original value. Please do not change. 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. 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. There are tests but none of them is testing scenario of path starting with "../". I have a fix and a test for issue 141092. *** Issue 134396 has been marked as a duplicate of this issue. *** I expanded the platform-unc job mentioned in bug #207060 comment #18 to run the same module list as NB-Core-Build. 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. (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. 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. |