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.
It would be better to not try at all to parse file which is locally removed (i.e. No file, but shown in explorer) Steps to reproduce: using CVS, checkout some file, remove it locally, schedule it to remove from CVS (cvs remove file), do NOT commit, click on it in explorer.
It is quite difficult to test for that file, since its FileObject exists and is valid. The fact that the file is not readable is discovered when the parser tries to read it. If we change the behaviour so that status of locally removed files will be `not parsed', unreadable files (e.g. user doesn't have permissions to read it) will remain marked as not parsed too.
[1074CE] JDK1.3.0.Beta-b07 ================== it's still last on CVS FS (and possibly on others GenericVCS FS).
Created attachment 94 [details] IDE log
I attache whole my IDE log where the latest exception are related to this bug with removing file from CVS FS. Excuse me that it is unfiltered but I belive you can find the right info.
XML and Form DataObjects may not handle the condition gracefully and/or annotate the exception.
The correct result of parsing an locally-removed file is a node "Error" beneath the Java node. There will be probably more descriptive hint on the file node taken from the Exception's message. Error reporting is the business of CloneableEditor support and other org.openide.text.* classes - a bug that they do not rethrow the IOException in the thread that was asking for the document was already reported (they show an exception dialog instead).
Resolved for 3.3.x or earlier, no new info since then -> closing.
Resolved for 3.4.x or earlier, no new info since then -> closing.