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.
Win XP, build 070220 Modify-save-modify-save main.rb in a newly created Ruby project. On the second save the system seems to try to save it again while it is still open for writing or reading or something like that, then notifies that it could not be saved, and then that it has been modified externally. FileSystem.runAtomic() problem?
Note that after this, main.rb cannot be saved. If closed and reopened (see end of attached log), it cannot be read.
Created attachment 38735 [details] log file
Also, this appears to halt the indexing process (this was restart after first run on a new userdir with ruby modules just downloaded).
Never mind about indexing, it's just moving slowly
On IDE restart, main.rb is now an empty file
I can not reproduce this. Is it reproducible for you? If so, can you provide more explicit instructions (modify-save-modify-save - I tried inserting a char and hitting ctrl-s plus some other permutations). I don't really do anything creative around file modification / file save so I'm not sure what could be specific about Ruby in this scenario. There's some SaveCookie logic in GsfDataObject.GenericEditorSupport which was copied from the java support; I'll go investigate that more closely, but if this is reproducible that would be infinitely easier to track down.
Basically two saves in rapid succession seem to collide - the second one happens while something else has the file locked (reparsing? Does anything work with raw java.io.File in there that you're calling?). I'll try to reproduce.
There shouldn't be any raw File IO happening - it uses the editor cookie to obtain document contents. I even have to do that for all the background indexed library files, because I want to perform various Document related operations on them (walking around the document to extract rdoc comments that I also process as part of indexing.) Have you been able to reproduce it?
Just happened again, after restart to install the new versions of the Ruby modules. I did a rapid select-text, ctrl-shift-t, save, select-more-text, ctrl-shift-t, save and the second save triggered it. See attached screen shot. Exception: java.io.IOException: The handle is invalid at java.io.FileOutputStream.close0(Native Method) at java.io.FileOutputStream.close(FileOutputStream.java:279) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj$1.close (FileObj.java:73) at java.io.FilterOutputStream.close(FilterOutputStream.java:143) at org.openide.text.CloneableEditorSupport$1SaveAsReader.run(CloneableEd itorSupport.java:828) at org.netbeans.editor.BaseDocument.render(BaseDocument.java:1202) at org.openide.text.CloneableEditorSupport.saveDocument(CloneableEditorS upport.java:855) at org.openide.text.DataEditorSupport.saveDocument(DataEditorSupport.jav a:288) at org.netbeans.modules.gsf.GsfDataObject$GenericEditorSupport$Environme nt$SaveSupport.save(GsfDataObject.java:128) [catch] at org.openide.actions.SaveAction.performAction(SaveAction.java:57) at org.openide.util.actions.NodeAction$DelegateAction$1.run(NodeAction.j ava:559) at org.netbeans.modules.openide.util.ActionsBridge.doPerformAction(Actio nsBridge.java:55)
I still don't know what to do about this issue; I've never seen it myself, and I don't think there are any raw File IO operations happening on the buffer.
Reassigning this issue to newly created 'ruby' component.
I haven't seen any other reports of this issue. I did however make one change related to this which might be related (?): In my DataObject implementation, I made this change: protected FileLock takeLock() throws java.io.IOException { - return this.getFile().lock(); + return ((MultiDataObject)this.getDataObject()).getPrimaryEntry().takeLock(); } This was just to reflect the code to do the same thing as the Java data object's implementation. Any chance this might have fixed the problem you're seeing?
The original code does the same thing. Unless you're actually doing file hiding (i.e. a Ruby DataObject represents two files, like a java file + a form file and you can't see the form file), then there's no difference between the two. Won't do any harm, although it might be trivially slower. I haven't seen this problem in some time either (but I'm also no longer using a windows machine, where the problem originally occurred).
Given that there have not been any other reports of this (and we do have some Windows users) I'm lowering the priority of this bug.
I've also never heard of this. Nor from any of our users. Lost of content would be surely reported. Might be fixed somehow(?), there were large changes in GSF and other parts. Tim please reopen, if you hit this problem. Hopefully not ;)
'ruby/gsf -> editor/csl' mass-move to be able to deleted gsf/ruby. Having to change the version and platform of all closed moved issues to the same due to Issuezilla deficiencies - choosing version == 6.5 and TM = 7.0.