(this is NetBeans IDE Dev (Build 090518))
Such behavior cause two reparse tasks + 2 reindex tasks run on each external modification

Integrated into 'main-golden', will be available in build *200905190201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/faeecad09ec7
User: Vladimir Voskresensky <vv159170@netbeans.org>
Log: workaround for IZ#165406: Two events for external modified file

The two events are fired only for the file opened in editor, right?

Is this really a regression? Since when?

yes, seems two events only for opened in editor (which is the normal case when use refactoring)
+ always double events for:
External updates: fileChanged
BaseFileObj$FileEventImpl[file=/var/tmp/vv159170/cnd-userdir/var/cache/index/s1/timestamps.properties,time=Tue May 19
19:20:02 MSD 2009,expected=false]
External updates: fileChanged
BaseFileObj$FileEventImpl[file=/var/tmp/vv159170/cnd-userdir/var/cache/index/s8/timestamps.properties,time=Tue May 19
19:20:02 MSD 2009,expected=false]

Not sure since when this regression happens, but our testers found that before Undo in refactoring worked fine, while
now sometimes it's broken

Also two events on file deleted.
File (configuration.xml) does not opened in the editor.
P2 because two events can create races in client code.

java.lang.Exception: Mark to reload project descriptor MakeConfigurationDescriptor@27216062 for project Freeway_1 in
ConfigurationDescriptorProvider@31993421
        at
org.netbeans.modules.cnd.makeproject.api.configurations.ConfigurationDescriptorProvider$ConfigurationXMLChangeListener.resetConfiguration(ConfigurationDescriptorProvider.java:353)
        at
org.netbeans.modules.cnd.makeproject.api.configurations.ConfigurationDescriptorProvider$ConfigurationXMLChangeListener.fileDeleted(ConfigurationDescriptorProvider.java:375)
        at org.openide.filesystems.FCLSupport$DispatchEventWrapper.dispatchEventImpl(FCLSupport.java:139)
        at org.openide.filesystems.FCLSupport$DispatchEventWrapper.dispatchEvent(FCLSupport.java:122)
        at org.openide.filesystems.FCLSupport.dispatchEvent(FCLSupport.java:99)
        at org.openide.filesystems.FileObject$ED.dispatch(FileObject.java:1014)
        at org.openide.filesystems.FileSystem$EventDispatcher.run(FileSystem.java:925)
        at org.openide.filesystems.EventControl.dispatchEvent(EventControl.java:77)
        at org.openide.filesystems.FileSystem.dispatchEvent(FileSystem.java:544)
        at org.openide.filesystems.FileObject.dispatchEvent(FileObject.java:469)
        at org.openide.filesystems.FileObject.fireFileDeletedEvent(FileObject.java:445)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.fireFileDeletedEvent(BaseFileObj.java:532)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.delete(FolderObj.java:329)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$2.call(BaseFileObj.java:580)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$2.call(BaseFileObj.java:575)
        at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:112)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.delete(BaseFileObj.java:588)
        at org.openide.filesystems.FileObject.delete(FileObject.java:359)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.performDelete(DefaultProjectOperationsImplementation.java:135)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.access$200(DefaultProjectOperationsImplementation.java:98)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$1.execute(DefaultProjectOperationsImplementation.java:201)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:655)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030)


java.lang.Exception: Mark to reload project descriptor MakeConfigurationDescriptor@27216062 for project Freeway_1 in
ConfigurationDescriptorProvider@31993421
        at
org.netbeans.modules.cnd.makeproject.api.configurations.ConfigurationDescriptorProvider$ConfigurationXMLChangeListener.resetConfiguration(ConfigurationDescriptorProvider.java:353)
        at
org.netbeans.modules.cnd.makeproject.api.configurations.ConfigurationDescriptorProvider$ConfigurationXMLChangeListener.fileDeleted(ConfigurationDescriptorProvider.java:375)
        at org.openide.filesystems.FCLSupport$DispatchEventWrapper.dispatchEventImpl(FCLSupport.java:139)
        at org.openide.filesystems.FCLSupport$DispatchEventWrapper.dispatchEvent(FCLSupport.java:122)
        at org.openide.filesystems.FCLSupport.dispatchEvent(FCLSupport.java:99)
        at org.openide.filesystems.FileObject$ED.dispatch(FileObject.java:1014)
        at org.openide.filesystems.FileSystem$EventDispatcher.run(FileSystem.java:925)
        at org.openide.filesystems.EventControl.dispatchEvent(EventControl.java:77)
        at org.openide.filesystems.FileSystem.dispatchEvent(FileSystem.java:544)
        at org.openide.filesystems.FileObject.dispatchEvent(FileObject.java:469)
        at org.openide.filesystems.FileObject.fireFileDeletedEvent(FileObject.java:445)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.fireFileDeletedEvent(BaseFileObj.java:532)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj.delete(FolderObj.java:329)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$2.call(BaseFileObj.java:580)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj$2.call(BaseFileObj.java:575)
        at org.netbeans.modules.masterfs.filebasedfs.FileBasedFileSystem.runAsInconsistent(FileBasedFileSystem.java:112)
        at org.netbeans.modules.masterfs.filebasedfs.fileobjects.BaseFileObj.delete(BaseFileObj.java:588)
        at org.openide.filesystems.FileObject.delete(FileObject.java:359)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.performDelete(DefaultProjectOperationsImplementation.java:135)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation.access$200(DefaultProjectOperationsImplementation.java:98)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$1.execute(DefaultProjectOperationsImplementation.java:201)
        at
org.netbeans.modules.project.uiapi.DefaultProjectOperationsImplementation$6$1.run(DefaultProjectOperationsImplementation.java:655)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:577)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1030)

First case file changed event: It looks like file is modified 2 times
a) first when close output stream is called
b) second when explicit fo.refresh is called from NbEditorUI.java

How to reproduce it? Does it happen always or is it random?

I am not sure how fs could merge these two events together. You talk about external modification but actually first is
internal modification when copy is performed. Second modification could be external in such case who performs file
change? I think if there is only internal change which sends first event then fo.refresh should not generate second
event. So it is important to know who performs external modification.

Regarding delete. How do you reproduce? Delete whole project from IDE? Is your listener added once?

>Regarding delete. How do you reproduce? Delete whole project from IDE? Is your listener added once?
Yes, delete project with sources.
I think listener added once.
Any way listeners shold be kept in waek hash set.

sorry, typo, weak

I tested with latest dev build, added logging but I get only first file change event, not second one invoked by refresh.
I have simple C++ App project with main.cpp (no VCS). Is there anything special I need to reproduce this? Is it random?
I am on Linux.

  Product Version         = NetBeans IDE Dev (Build 090525)
  Operating System        = Linux version 2.6.28-12-generic running on i386
  Java; VM; Vendor        = 1.6.0_14; Java HotSpot(TM) Client VM 14.0-b15; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_14-b07
  Java Home               = /usr/java/jdk1.6.0_14/jre
  System Locale; Encoding = en_US (nb); UTF-8

It looks like there was something more involved perhaps some VCS? (It looks like something is touching file after first
event.)

I attach my simple project. I renamed int variable to k a Undo this change. I added log to
ModelSupport.ExternalUpdateListener.fileChanged.

Created attachment 82731 [details]
Simple C++ project I used to reproduce this issue

Re delete. Yes I get 2 file deleted events: One for nbproject/configurations.xml, second one for
nbproject/private/configurations.xml. It is correct IMO as code adds FCL to both files. If you want to process only one
event (ie. perform reset configuration just once) you must handle this in your code somehow.

You are right. Make project add listeners on:
- nbproject/configurations.xml
- nbproject/private/configurations.xml

please, do not close this IZ after comment from Alexander. 
The original issues is still in place (any file opened in editor's tabs send two events about modification)

Passing back to Jiri. I am not able to reproduce on Linux (2 machines). I am able to reproduce it on Win XP. On Win
simple test case Refactor -> Rename variable and Undo generates 2 file change events. In this case I get file change
event from refresh before second event. It depends when modified flag is set in fs implementation. Second event is sent
on fo's output stream close but depending when fo is considered as modified it might be correct to fire file change
event when someone calls fo.refresh on fo which is already modified. Not sure if it is possible to synchronize this
somehow or if it is possible to fix this. Jiri please look at it soon. Jiri also works on Windows. I will attach my ide log.

Created attachment 82983 [details]
IDE log

Note: In my ide log first event with call stack comes from Refactor -> Rename. Next 2 events come from Refactor -> Undo.

I am not able to reproduce it in IDE but I can simulate it in a test. It is really possible that fileChanged event is
fired twice for a single change if a thread is closing output stream and other thread calls FileObject.refresh(). It is
not easy to somehow synchronize it because we don't know when operating system stores a new timestamp for modified file.
There is always some delay. Possibly we can remember a timestamp of lastly fired event but this will add extra bytes for
every FileObject instance.

Created attachment 83095 [details]
Test case.

Jiri, on Solaris box with NFS based project it is reproducible from IDE (but have test is much better :-)).

what i've seen in debugger:
- event object has information about last modified time and both event objects have the same time info. Can it be used
to prevent second event? 

> - event object has information about last modified time and both event objects have the same time info. Can it be used
to prevent second event? 

It is a time when event was created. Thus it can differ even they are two events for the same change.

I meant another field.
BaseFileObje$FileEventImpl has field "file" which is "FileObj" with fields
- "lastModified" and "realLastModifiedCached"
And my remark was that duplicated BaseFileObje$FileEventImpl objects (having different "time" field) points to the same
"file" with correct "lastModified" and "realLastModifiedCached" info

Yes, it would solve this case. Need to say that two consequent changes in one millisecond will fire just one event.
Maybe not issue in real-life but it is often used in tests.

I am not sure it is feasible to prevent all sorts of event duplications. We are lucky to deliver at least some events...

But I think I can solve the problem with FileChangeEvent: core-main#
7e87916d8faa, as that is by far the most common manifestation of the problem, I think fixing that might be enough.

Thanks Jirko for writing such nice test!

Integrated into 'main-golden', will be available in build *201004170515* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7e87916d8faa
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #165406: When FileObject.getOutputStream exist, don't generate superfluous change events during refresh