Created attachment 3504 [details]
ide.log from nb3.3beta5 build #200111201425

It is properties module bug.

Ops missed the module - nice start of the day ;-)

However I'm not an expert on properties module, I think these 
problems are not caused by this module.
If you look at the attached ide.log, you see a failure of 
deserializing the "properties" top component. All the other 
exceptions from PropertiesOpen.PropertiesCloneableTopComponent (I 
found 3 in the log) are caused by that the top component is in an 
inconsistent state (was not initialized).

The top component deserialization exceptions is:

org.openide.filesystems.FileStateInvalidException
	at org.openide.loaders.DataObject.find(DataObject.java:428)
	at org.openide.loaders.DataNode$ObjectHandle.getNode
(DataNode.java:643)
	at org.openide.windows.TopComponent.readExternal
(TopComponent.java:536)
	at org.openide.windows.CloneableTopComponent.readExternal
(CloneableTopComponent.java:160)
	at 
org.netbeans.modules.properties.PropertiesOpen$PropertiesCloneableTopC
omponent.readExternal(PropertiesOpen.java:745)
	at org.openide.windows.TopComponent$Replacer.readObject
(TopComponent.java:761)
... etc ...

According to Dafe, root is in the deserializing phase of properties
topcomponent:

Tue Nov 20 18:06:17 CET 2001:
org.openide.filesystems.FileStateInvalidException: null
org.openide.filesystems.FileStateInvalidException
	at org.openide.loaders.DataObject.find(DataObject.java:428)
	at org.openide.loaders.DataNode$ObjectHandle.getNode(DataNode.java:643)
	at org.openide.windows.TopComponent.readExternal(TopComponent.java:536)

<...>

That's what I've written above...

So why have you reassigned this back to issues@properties ??

Because exception thrown during deserialization of some component
which belongs to properties module is not winsys problem, I think. IMO
problem is either in properties module, which has some strange data
object asociated with its top component, or in data-file system
itself. It looks like properties' top component has some strange node
asociated with it, and that this node somehow becomes invalid...that's
why I would like to start in properties module, and only then move
further (but surely not to the winsys).

Sounds reasonably...

But I'm not able to reproduce the problem, so I cannot debug it to 
find out what node/data object is associated with the serialized top 
component. I see nothing wrong in properties code at the first sight.

Honzo, please provide some reproducible case...

I have just another idea: could not this be some timing issue around 
mounting filesystems during project switch? It looks like because it 
happens very irregularly, and the failure is in FileObject.isValid().
Radek, could you look at it?

Created attachment 3516 [details]
patch of DataObject

I've added a patch of DataObject to print the name of the invalid file
DataObject.find:

if (!fo.isValid())
  throw new FileStateInvalidException(fo.getPackageNameExt('/', '.'));

something b/w file system and data system

I tried tough to repro this issue but without succes. So no more info
for now. If the stacktraces cannot help, then will be good at least
provide better annotation - i.e. inform what file is invalid, as Tomas
provided.

I've just encountered the FileStateInvalidException during startup.
With the patched DataObject it shows that "Bundle.properties" is not 
a valid file - but it should be valid for sure...

Note that this exception even did not go through PropertiesOpen top 
component, but through NbNodeOperation.Sheet (so it is not dependent 
on top component type).


org.openide.filesystems.FileStateInvalidException: Bundle.properties
  at org.openide.loaders.DataObject.find(DataObject.java:428)
  at org.openide.loaders.DataNode$ObjectHandle.getNode
(DataNode.java:643)
  at org.openide.nodes.DefaultHandle.getNode(DefaultHandle.java:51)
  at org.openide.nodes.DefaultHandle.getNode(DefaultHandle.java:51)
  at org.openide.nodes.FilterNode$FilterHandle.getNode
(FilterNode.java:1116)
  at org.openide.nodes.NodeOp.fromHandles(NodeOp.java:405)
  at org.netbeans.core.NbNodeOperation$Sheet.readExternal
(NbNodeOperation.java:455)
  at org.openide.windows.TopComponent$Replacer.readObject
(TopComponent.java:761)

I don`t think that the problem is in filesystems. If that invalid 
FileObject were from MultiFileSystem then I would hasitate. But 
because Bundle.properies is probably from ExLocalFileSystem then it 
should be more transparent. AbstractFileObject is invalid:
1/ after delete
2/ during refresh, before fileDeleted event is fired
3/ deserialization, if filesystem of AbstractFileObject is not find 
in repository, which is most probable. 

Please Vita, could you verify point 3/.

My explanantion is more guess than solid standpoint, but from reports 
attached here it seems to me that filesystem repository isn't 
up-to-date at the time when window system reopens editor's 
TopComponents. That's why the deserialized FileObject is invalid and 
exception is thrown from DataObject.find(). This scenarion is possible 
as long as there is no synchronization between AutomountSupport and 
window system, they both just listen to changes from MultiFileSystem 
and do their job without knowing of each other.

The fix was done in SessionManager, which waits now for the 
AutomountSupport to refresh filesystems repository before the project 
open event is fired to listeners (window system). This definitely 
improves the project switching mechanism, but may not truly resolve 
the problem, please try to verify and let me know in case of troubles.

Fixed in main trunk.

Do not see this in last build. Verifying.

Resolved for 3.4.x or earlier, no new info since then -> closing.