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.
Create a java project, add a java class. Open the java file in the editor and make some change -- do not save --. Open a command line shell, go to the directory where this file is and delete the file. Now switch back to the IDE and focus the editor. You'll automatically get a message box that says "File [filename] was change to read only. All changes will be discarded. [OK] [Cancel]". Bug #1: This message is wrong. The file is not readonly. It's been deleted. If you hit OK, the editor will be closed. Seems to be ok. Bug #2: If you hit Cancel, the editor will stay, which is good, but it will be useless, which is bad. You won't be able to save your changes. Other user actions produce varying message in popups and exceptions on the console (see attached). For example, the title of the window is deleted after the first save attempt.
Created attachment 32913 [details] stack trace when attempting to save changed editor after deleting underlying file.
Created attachment 32914 [details] Informational trace after cancelling disposal of editor if underlying file is deleted and there are unsaved changes.
Ok. If you want to suggest your preferred fix, then go on and tell me...
I'll think about it. The manual deletion argument is a bit arcane, but I suspected this might also happen if a file was removed while open due to a VCS update. I have not tested this - no dummy VCS to bounce against.
1) incorrect message - the message is incorrect because the low level java.io.File api used to check for readonly also returns the same result if the file is non existent. File existence could be checked for separately at a reasonable place in NetBeans to differentiate these two cases. If the file really is readonly, no changes is no problem just make editor readonly. If there are changes maybe offer "Save As" option? Better handled on a save attempt from the user rather than on IDE focus gained. 2) Closing the editor if no changes, or dying in place if there are changes is bad. What about, for either case (file modified or not), when the top component regains focus, inform the user that the underlying file has been removed and offer them a choice of closing the editor or continuing (in which case editor is marked modified so that it'll be saved even in the "no changes" case).
Heh, just reread my original report, looks like we already sort of try to do #2 and maybe what you are asking me is how to keep an editor w/ no underlying dataobject open? How do we do it today w/ new files? Can we have unsaved but named open files?
We have "Save as..." now. So the only outstanding issue is the wrong message, if I am not mistaken. Plus log messages like, which are not nice either, but otherwise harmless: java.lang.IllegalStateException: The data object MasterFileObject@e5a644 [space/tmp/WebApplication3/src/java/test/Test.java] is invalid; you may not call getNodeDelegate on it any more; see #17020 and please fix your code [catch] at org.openide.loaders.DataObject.getNodeDelegate(DataObject.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
moving opened issues from TM <= 6.1 to TM=Dev
Reassigning all openide/data systems issues to the new owner jskrivanek.
This bug was reported against NetBeans IDE 6.0 or an older release, or against a non-maintained module. NetBeans team does not have enough resources to get to this issue, therefore we are closing the issue as a WONTFIX. If you are interested in providing a patch for this bug, please see our NetFIX guidelines for how to proceed. We apologize for any inconvenience. Thank you. The NetBeans Team