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.
1. Run NB [dev feb 05] on fresh userdir $ud (e.g. /dev/shm/testme) w/ flag -J-Dorg.netbeans.modules.xml.core.actions=0 2. Make new mount $ud in addition to existing $ud/sampledir 3. Order $ud above $ud/sampledir 4. Make foo.xml (simple XML doc) in $ud/sampledir 5. Introduce unmatched <bar> element or other syntax error 6. Run "Check XML" 7. Click on error hyperlink 8. Second copy of foo.xml opened! 9. Close the extra copy of the XML file. 10. Change order again so that $ud below $ud/sampledir 11. Repeat #6 & #7 12. No second copy opened, just focuses original Problem is in InputOutputReporter.display. (1) Explicit tricks with file: are bad, use URLMapper. (2) Converting FileObject -> URL -> File -> FileObject is lossy. Suggest for #2 that the XML parser be passed a special URL, not file:, which encapsulates the original filesystem. Then no conversion would be necessary in most cases, unless the user actually includes a literal file: system ID (as opposed to relative system IDs). nbfs: is not enough since relative system IDs might pass outside the mount point. So make a special URL protocol - you can declare it globally in the system by adding the protocol handler to lookup; or just pass it to the URL constructor. The protocol should encode the filesystem system name (like nbfs:) followed by the full file path (like file:); when resolved to a FileObject, check first on the given filesystem, only then on other filesystems. Or pass a file: URL to the parser as now, but also keep some context indicating the original FileObject that the action was invoked on. For all hyperlinks in the output, attempt to resolve them within that same filesystem if possible - note that FileUtil.fromFile gives an array, so check first if any element has the same FS as the context FileObject, and if not use the first element arbitrarily. Also note that log includes some mysterious exceptions which probably indicate bugs in the code.
Created attachment 8817 [details] Log messages from abovementioned steps
It should disappear once issue 25661 takes effect.
It is slightly related to the issue 39692.
Presumably fixed by masterfs.
Verified - fixed a long time ago