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.
Created attachment 114729 [details] Picture describing the bug (only drive letter is updated automatically) When using any file view in NetBeans under Windows (Project, Files, Favourites etc.) that are created using UNC style pathes (e.g. \\MyServer\myShare\myDirectory) instead of using drive letters (e.g. Y:\myDirectory) the automatic update of the view does not work at all. If you create or delete files externally (e.g. using a build script) the file view is not updated. The only way to update is to restart the IDE, or selecting "Refresh Folder" after deselecting "Enable auto-scanning of sources" in Options -> Miscellaneous -> Files. Attached is a picture of an example. Both test and test_1 are the same directory, one using the unc path and the other the drive letter. Only the directory using the drive letter is updated when the directory is filled with files or subdirectories. I just found one solution on the internet that says "Use drive letters instead" some people here using the software have to use unc pathes since our version control system causes problems with drive letters. So far I have checked with version of NetBeans from 6.8 to 7.1. All failed. Also I tried running it under Windows XP and Windows 7. On both versions the described effect occoured.
I just checked the IDE Log and found the following output: WARNING [org.netbeans.modules.masterfs.watcher.Watcher]: Cannot add filesystem watch for //bh5400/c$/mytemp/test: java.io.IOException: wrong path: //bh5400/c$/mytemp/test WARNING [org.netbeans.modules.masterfs.watcher.Watcher]: Cannot add filesystem watch for //bh5400/c$/mytemp/test/findMe: java.io.IOException: wrong path: //bh5400/c$/mytemp/test/findMe This 2 Warning come up again and again. I hope this helps.
In the sources of masterfs i found a WindowsNotifier.java that is pretty strict about the type of file: public @Override Void addWatch(String path) throws IOException { if (path.length() < 3 ) throw new IOException("wrong path: " + path); String root = path.substring(0, 3).replace('/', '\\'); if (root.charAt(1) != ':' || root.charAt(2) != '\\') { throw new IOException("wrong path: " + path); } if (rootMap.containsKey(root)) return null; // already listening path = root; // listen once on the rootpath instead this only works for drive letters (X:\) for UNC pathes it will throw a "wrong path: " exception.
Hello again, i changed the code in the WindowsNotifier a bit: public @Override Void addWatch(String path) throws IOException { if (path.length() < 3) { throw new IOException("wrong path: " + path); } String root = null; if (path.charAt(1) == ':') { // classic drive letter (e.g. C:\) root = path.substring(0, 3).replace('/', '\\'); if (root.charAt(2) != '\\') { throw new IOException("wrong path: " + path); } } else { // check if it is unc path String normedPath = path.replace('/', '\\'); if (normedPath.startsWith("\\\\")) { int thirdBackslash = normedPath.indexOf('\\', 3); if (thirdBackslash != -1) { int endOfRoot = normedPath.indexOf('\\', thirdBackslash + 1); if (endOfRoot == -1) { endOfRoot = normedPath.length(); } root = normedPath.substring(0, endOfRoot); } else { throw new IOException("wrong path: " + path); } } } if (root == null) { throw new IOException("wrong path: " + path); } if (rootMap.containsKey(root)) { return null; // already listening } path = root; // listen once on the rootpath instead ....... The update on UNC-Pathes now works, I had however one crash when removing directories.
Thanks for the investigation.
*** Bug 206182 has been marked as a duplicate of this bug. ***
I tried to simulate the problem on my VirtualBox Windows, but connecting to \\VBOXSRV\Homes was not successful it yielded an exception. Anyway I decided to apply the changes. They seem reasonable and may they can work on real samba implementation: ergonomics#9e229d6d3f7c Please verify.
Integrated into 'main-golden', will be available in build *201201250600* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/9e229d6d3f7c User: Jaroslav Tulach <jtulach@netbeans.org> Log: #207060: Allow listening on UNC paths
Confirmed: it now works in Dev 201202060400 BUT! Unfortunately it also throws a NullPointerException when a file is deleted externally and a java.lang.AssertionError when it is created. Please review and fix. Also files don't open when drag'n'dropped to the IDE from the network folder under Windows.
Created attachment 115519 [details] java.lang.AssertionError thrown when creating file externaly Added stacktrace for java.lang.AssertionError
Created attachment 115521 [details] Stacktrace of NullPointerException Added stacktrace for NullPointerException that is (not always) thrown, when a folder is deleted externally.
Created attachment 115522 [details] Stacktrace of java.lang.AssertionError Added stacktrace for java.lang.AssertionError thrown when clicking a folder on a Windows-share.
Created attachment 115523 [details] java.lang.AssertionError when drag-dropping file from samba share to IDE Stacktrace of exception thrown when a network resource (here: a Linux samba share) in Windows explorer is opened (\\123.456.78.90\folder) and a file from that resource is drag'n'dropped on the IDE.
I'd say the exception is unrelated to original problem and caused by SimpleFileOwnerQueryImplementation or FileObject.toURI which has been introduced by issue 207294.
The URL was always wrong but #207294 (and related API changes needed for remote FS support) just triggered its usage as a URI more commonly than had previously been the case. Unfortunately java.io.File.toURI is wrong for UNC paths; java.nio.file.Path.toUri gets it right. Similarly, java.io.File.<init>(URI) does not work for UNC paths, while java.nio.file.Paths.get should be right. I think the problem is in masterfs in FileBasedURLMapper; for \\server\share\path you want to produce file://server/share/path, not file:////server/share/path which is bogus. URLMapper.DefaultURLMapper.toURL is also wrong, though FileBasedURLMapper probably supersedes this in practice. getFileObjects(URL) impls are also broken, of course. See bug #46813 comment #78 for more background. We may need FileUtil methods delegating to Path.toUri and Paths.get(URI) when running on JDK 7, and on JDK 6 using File.toURI and File.<init>(URI) for most paths but specially handling UNC paths. A Jackpot script would make it easy to update usages. Once we switch to JDK 7 as a baseline then we can deprecate these methods and update the Jackpot script to convert to the standard.
(In reply to comment #10) > Created attachment 115521 [details] > Stacktrace of NullPointerException Filed bug #208580.
If you want me to work on the suggestion given in comment #14, just assign to me. By the way, just by mounting NB sources on a shared drive (e.g. \\vboxsvr\something under XP in VirtualBox) and running projectapi tests on JDK 7, you get a host of colorful errors: 1. IAE "URI has an authority component" from java.io.File.<init> in org.netbeans.JarClassLoader$JarURLStreamHandler.openConnection (which means that any JDK 6-compatible utility method must live in openide.util, not openide.filesystems) 2. NPE from org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.getFileObject, probably related to bug #208580 3. The AE from FileObject.toURI mentioned here Clearly we need to set up a Hudson job to run all our tests in this mode!
> Clearly we need to set up a Hudson job to run all our tests in this mode! Jiří, Petr can you help me setting the right hudson job up?
I have prepared platform-unc job at Hudson4QE. Custom build script is modified that NetBeans bits and test distribution are unzipped into \\Hudson4qe-xp\unc\ folder which points to C:\unc on the same slave (XP-slave1). If build is aborted, it shows no results and no artifacts because they are not copied from UNC path to hudson workspace.
*** Bug 209422 has been marked as a duplicate of this bug. ***
Should be a release note for Beta at least.
*** Bug 212475 has been marked as a duplicate of this bug. ***
I have fixed the conversion to URI in ergonomics#2fce462a0d55
2fce462a0d55 is a good start, but not enough. Most of the problems mentioned in comment #16 still apply. A properly tested API in a basic component like org.openide.util would be ideal, but even a temporary solution that made our test suites pass would probably suffice for 7.2.
Created attachment 119787 [details] Fixes for a handful of problems projectapi tests still fail with: java.lang.AssertionError: No factory for //SERVER/ this: \\SERVER@123:456 at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.getFileObject(FolderObj.java:126) at org.netbeans.api.project.TestUtil$TestProjectFactory.loadProject(TestUtil.java:202)
Integrated into 'main-golden', will be available in build *201205240002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2fce462a0d55 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #207060: UNC paths are converted to URI with host part
I have applied Jesse's changes as ergonomics#1c6ef06969ad
(In reply to comment #26) > I have applied Jesse's changes Some of them, not all, and as I said there were other problems in masterfs beyond my knowledge. 1c6ef06969ad is at least closely related to 2fce462a0d55. Other issues can be tracked in the blocking list of bug #46813.
Integrated into 'main-golden', will be available in build *201205290002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4416e60f3437 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #207060: Refinement to not assert in FileOwnerQueryTest
*** Bug 213141 has been marked as a duplicate of this bug. ***
*** Bug 213415 has been marked as a duplicate of this bug. ***
*** Bug 213143 has been marked as a duplicate of this bug. ***
*** Bug 213014 has been marked as a duplicate of this bug. ***
*** Bug 209466 has been marked as a duplicate of this bug. ***
*** Bug 213743 has been marked as a duplicate of this bug. ***
JDK bug was closed as WONTFIX