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 Java Application with Main class - rename "main" to "main12" - try Refactoring->Undo => No changes, "main12" remains instead of old "main" function
I faced the problem on today's fresh build of trunk on Solaris. weekend's build of trunk on Linux is fine. It seems, that file is not reloaded in editor after undo from disk (on disk content is OK) + someone holds lock on file, so it's impossible to save it again and after "Cancel" saving action the content of file is lost - file is empty on disk :-(
I will investigate.
I cannot reproduce it and I am not aware of any change in refactoring modules that could caused it. Is your project version controlled (svn, cvs, hg, ...)?
It was reproducible with sample java project as (=> no vcs) Project was created in NFS ${HOME} directory It is reproducible for C++ refactoring as well. => may be system specific problem of implementation of file system? I will build now new trunk and check from some other OSes by creating project in NFS home directory
It is reproducible problem for some workstations with Solaris which I have available: Product Version = NetBeans IDE Dev (Build 081209) Operating System = SunOS version 5.10 running on x86 Java; VM; Vendor = 1.5.0_12; Java HotSpot(TM) Client VM 1.5.0_12-b04; Sun Microsystems Inc. Runtime = Java(TM) 2 Runtime Environment, Standard Edition 1.5.0_12-b04 and Product Version = NetBeans IDE Dev (Build 081209) Operating System = SunOS version 5.10 running on x86 Java; VM; Vendor = 1.6.0_07; Java HotSpot(TM) Client VM 10.0-b23; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_07-b06 It works fine on Linux Product Version = NetBeans IDE Dev (Build 081209) Operating System = Linux version 2.6.5-7.244-smp running on amd64 Java; VM; Vendor = 1.6.0_10; Java HotSpot(TM) 64-Bit Server VM 11.0-b15; Sun Microsystems Inc. Runtime = Java(TM) SE Runtime Environment 1.6.0_10-b33
Same on Solaris for JDK: Java; VM; Vendor = 1.6.0_11; Java HotSpot(TM) Client VM 11.0-b16;
I have tried on OpenSolaris with local ZFS and it works. Please attach your ${nb.userdir}/var/log/messages.log.
message.log has no exceptions. But, when I've tried to make refactoring once more, I've got: java.lang.Throwable: Locked by: at org.openide.filesystems.FileLock.<init>(FileLock.java:80) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.LockForFile.<init>(LockForFile.java:88) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.LockForFile.tryLock(LockForFile.java:99) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.lock(FileObj.java:277) at org.openide.loaders.MultiDataObject$Entry.takeLock(MultiDataObject.java:1189) at org.netbeans.modules.form.FormEditorSupport$Environment.takeLock(FormEditorSupport.java:1367) at org.openide.text.DataEditorSupport$Env.markModified(DataEditorSupport.java:744) at org.openide.text.CloneableEditorSupport.notifyModified(CloneableEditorSupport.java:1829) at org.netbeans.modules.form.FormEditorSupport.notifyModified(FormEditorSupport.java:571) at org.openide.text.CloneableEditorSupport.callNotifyModified(CloneableEditorSupport.java:1798) at org.openide.text.CloneableEditorSupport$Listener.vetoableChange(CloneableEditorSupport.java:2710) at org.netbeans.editor.BaseDocument.notifyModify(BaseDocument.java:1819) at org.netbeans.editor.BaseDocument.atomicUnlockImpl(BaseDocument.java:1778) at org.netbeans.editor.GuardedDocument.runAtomic(GuardedDocument.java:324) at org.openide.text.NbDocument.runAtomic(NbDocument.java:384) at org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:226) at org.netbeans.api.java.source.ModificationResult.commit(ModificationResult.java:190) at org.netbeans.modules.refactoring.java.plugins.RetoucheCommit.commit(RetoucheCommit.java:85) at org.netbeans.modules.refactoring.api.RefactoringSession.doRefactoring(RefactoringSession.java:117) at org.netbeans.modules.refactoring.spi.impl.ParametersPanel$8.run(ParametersPanel.java:375) Caused: org.openide.filesystems.FileAlreadyLockedException: /home/vv159170/NetBeansProjects/AnagramGame6/src/com/toy/anagrams/ui/Anagrams.java at org.netbeans.modules.masterfs.filebasedfs.fileobjects.LockForFile.registerLock(LockForFile.java:111) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.LockForFile.tryLock(LockForFile.java:100) at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FileObj.lock(FileObj.java:277) at org.openide.filesystems.FileObject.getOutputStream(FileObject.java:521) at org.netbeans.modules.refactoring.spi.BackupFacility$DefaultImpl.copy(BackupFacility.java:272) at org.netbeans.modules.refactoring.spi.BackupFacility$DefaultImpl.restore(BackupFacility.java:231) at org.netbeans.modules.refactoring.spi.BackupFacility$DefaultHandle.restore(BackupFacility.java:168) at org.netbeans.modules.refactoring.java.plugins.RetoucheCommit.rollback(RetoucheCommit.java:98) Caused: java.lang.RuntimeException at org.netbeans.modules.refactoring.java.plugins.RetoucheCommit.rollback(RetoucheCommit.java:100) at org.netbeans.modules.refactoring.api.RefactoringSession.undoRefactoring(RefactoringSession.java:163) at org.netbeans.modules.refactoring.spi.impl.UndoManager$SessionUndoItem.undo(UndoManager.java:596) at org.netbeans.modules.refactoring.spi.impl.UndoManager.undo(UndoManager.java:221) at org.netbeans.modules.refactoring.spi.impl.UndoAction.performAction(UndoAction.java:96) at org.openide.util.actions.CallableSystemAction$1.run(CallableSystemAction.java:118) at org.netbeans.modules.openide.util.ActionsBridge$ActionRunnable.actionPerformed(ActionsBridge.java:111) at org.netbeans.core.ModuleActions.invokeAction(ModuleActions.java:105) at org.netbeans.modules.openide.actions.ActionsBridgeImpl.invokeAction(ActionsBridgeImpl.java:53) at org.netbeans.modules.openide.util.ActionsBridge$ActionRunnable.doRun(ActionsBridge.java:102) at org.netbeans.modules.openide.util.ActionsBridge$1.run(ActionsBridge.java:71) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:573) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1005)
It is really strange. RefactoringSession.doRefactoring calls LifecycleManager.getDefault().saveAll() after file changes that should save all documents and it should result in releasing all file locks. Is not there another exeption? Have you tried to reproduce it on a local filesystem? I have found out that jskrivanek did some changes of file locking recently. Jirko could it relate?
Do you have any loggers? I can enable them to get at least something in message.log
Jan, you are right! Creating project in /var/tmp helps, so looks like problem with network folders (and of course in swan I have NIS home)
I am not aware of any big changes in file locking.
I has been experimenting a bit with NFS today. I am still not able to reproduce it. I have a theory that it could be caused by time lag. In one point the javac notified me that there is wrong class in renamed file. It took some time to refresh to proper state. So if you perform refactoring undo too early before the lock file is removed it could result in that FileAlreadyLockedException.
I think that requested information has been already provided in desc12 - so removing INCOMPLETE keyword.
Still cannot reproduce + anyone else has not encountered anything similar -> lowering to P3. jskrivanek: Jirko, is there any logger of file locking available in filesystems? I have not found any. vv159170: Vladimir, could you try to reproduce it with the latest build please? There has been already done some bug-fixes to properly refresh class index of file events in java.source module. Some details about locking inside data systems layer could be collected with the org.openide.text.DataEditorSupport logger enabled. Please attach your messages.log afterwards.
In today's trunk it works fine again.
BTW, it should be obvious from the stack trace who locked the file before. In case of stack trace in desc9 firstly lock is acquired by DataEditorSupport$Env.markModified and before it is released it is requested from BackupFacility$DefaultImpl.copy.
Who locks is obvious but who and when unlocks is not clear. Especially in this case. The refactoring calls LifecycleManager.saveAll before it starts to perform modifications. Refactoring undo/redo is possible just in case there has been no document modification before. Usually it works as expected but in cases like this issue it would be useful to have a logger of file locks available.