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.

Bug 9049 - Invalid lock for file - FSException
Summary: Invalid lock for file - FSException
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P1 normal (vote)
Assignee: akemr
URL:
Keywords:
: 8666 9937 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-01-09 19:48 UTC by Josef Kozak
Modified: 2008-12-22 21:39 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Proposed fix of FileEntry.java (2.66 KB, patch)
2001-04-04 08:34 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Josef Kozak 2001-01-09 19:48:48 UTC
While renaming the name of a class and the name of it's constructor (in editor)
and then renaming the name of the corresponding file (in explorer) to the same
value, after saving this file a FSException exception is occured.

(in ForteFJ -build 1160- there is another one exception in setter while
renaming the file)


org.openide.filesystems.FSException: Invalid lock for file ClasssX.java in
C:\Program Files\NetBeans\Development.

        at org.openide.filesystems.FSException.io(FSException.java:72)

        at org.openide.filesystems.AbstractFileObject.testLock
(AbstractFileObject.java:215)

        at org.openide.filesystems.AbstractFileObject.getOutputStream
(AbstractFileObject.java:174)

        at org.openide.text.DataEditorSupport$Env.outputStream
(DataEditorSupport.java:305)

        at org.openide.text.CloneableEditorSupport.saveDocument
(CloneableEditorSupport.java:379)

        at org.openide.text.EditorSupport$Del.superSaveDocument
(EditorSupport.java:711)

        at org.openide.text.EditorSupport.saveDocument(EditorSupport.java:258)

        at org.netbeans.modules.java.JavaEditor.saveDocument
(JavaEditor.java:380)

        at org.netbeans.modules.java.JavaEditor.saveDocument
(JavaEditor.java:362)

        at org.openide.text.EditorSupport$EntryEnv.save(EditorSupport.java:810)

        at org.openide.actions.SaveAction.performAction(SaveAction.java:49)

        at org.openide.util.actions.NodeAction.performAction(NodeAction.java:93)

        at org.openide.util.actions.NodeAction.actionPerformed
(NodeAction.java:84)

        at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:67)

        at org.openide.util.Task.run(Task.java:124)

[catch] at org.openide.util.RequestProcessor$ProcessorThread.run
(RequestProcessor.java:562)
Comment 1 rmatous 2001-01-16 13:32:59 UTC
Probably problem lies anywhere in EditorSupport and for this bug is not
responsible org.openide.filesystems. Method FileObject.getOutputStream expects
FileLock parametr and validates it in testLock. Because FileLock parameter is
null, than is not validated in testLock and FSException is fired.

The problem is caused in DataEditorSupport.Env.outputStream() in call: return
getFileImpl ().getOutputStream (fileLock), where fileLock is null. Method
DataEditorSupport.Env.changeFile () is responsible for setting fileLock
(fileLock = takeLock()). But when DataObject is renamed
EditorSupport.EntryEnv.propertyChange is called as notification. From
propertyChange is called changeFile (), but takeLock () is not called, because
methods returns prematurely:
        protected final void changeFile () {

            FileObject newFile = getFile ();

            if (newFile.equals (fileObject)) {
                // the file has not been updated
                return;
            }
            ....
Comment 2 Jan Zajicek 2001-03-19 15:11:03 UTC
Reassigning to editor because of the Radek's comment and increasing priority
of this bug to P2, because of simple steps to reproduce and big impact at the
user (cannot save data from editor).
Comment 3 Jan Zajicek 2001-03-19 15:52:45 UTC
x
Comment 4 Jan Zajicek 2001-03-19 15:54:08 UTC
*** Issue 9937 has been marked as a duplicate of this issue. ***
Comment 5 Miloslav Metelka 2001-03-30 11:27:53 UTC
I don't know what's the proper fix for this openide bug. I think Yarda or
someone else should take care about this.
Comment 6 Jan Zajicek 2001-03-30 12:33:19 UTC
This is bad behaviour and user cannot save his data. Yarda can you suggest any
solution?
Comment 7 Jaroslav Tulach 2001-04-03 13:22:32 UTC
Steps to reproduce?  I tried:

1. open a java file named GetNode
2. change the name of class to Get
3. change the name of constructor to Get
=> the file renamed on disk to
4. then I renamed the file on disk to Get and also I tried Get1

Comment 8 Jan Zajicek 2001-04-03 14:40:07 UTC
Now it works for mee too, seems that the behaviour has changed ;-)
Comment 9 Josef Kozak 2001-04-03 14:44:12 UTC
Yarda, 5. step to reproduce is "Save".

After modification of the file in editor (a name of class and constructor) you 
don't have to save the file, first rename the file in explorer and then save it.


Comment 10 Josef Kozak 2001-04-03 17:00:22 UTC
Sorry, now IDE really changed behaviour (NB 3.2 build 19), my last additional 
comment was related to NB 3.2 build 16, BUT the FSException persists in other 
steps to reproduce. So here it is:

1. rename only class name in editor, e.g. Get -> GetNode (it does not lead to 
synchronization with explorer)

2. rename the corresponding file in explorer to the same name as class in editor
(Get -> GetNode), there is a BUG, because the class in editor is automaticly 
renamed to GetNodeNode and it is not in synchronization with explorer

3. rename constructor of class in editor to GetNodeNode (now the classname and 
constructor are consistent AND it does lead to synchronization with explorer, 
so node in explorer is automaticaly renamed to GetNodeNode)

4. try to save this file -> FSException will occur

Comment 11 Jaroslav Tulach 2001-04-04 08:34:44 UTC
Created attachment 988 [details]
Proposed fix of FileEntry.java
Comment 12 Jaroslav Tulach 2001-04-04 08:38:47 UTC
The problem is not just in Java sources, but is general.

1. Create a text file
2. Open and edit it
3. Rename it in explorer (while document is modified)
4. Try to save the content of document

You'll receive the exception.


My fix should solve the worst type of problem and I think it is suitable for
3.2, but for new versions. But it is not bulletproof, probably we need better
implementation with better synchronization for next versions. 

Comment 13 akemr 2001-04-04 09:39:02 UTC
Fixed. Fix will be in dev build #161 and release32 build #21

(rename(), move() and delete() methods modified to don't release lock,
if file was locked previously)
Comment 14 Jan Zajicek 2001-04-11 09:32:15 UTC
*** Issue 8666 has been marked as a duplicate of this issue. ***
Comment 15 pzajac 2002-10-22 09:54:40 UTC
verified.
Comment 16 Quality Engineering 2003-07-01 16:33:57 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.