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.
[Nb Build 200207080100, jdk1.4.0_01] Steps to reproduce: =================== 1) open .java in Source Editor and modify it 2) remount filesystem (change Root Directory in Property Editor), the Source Editor remains opened 3) click the Source Editor, question dialog "File is modified. Save it?" appears 4) click "Yes" 5) remount the filesystem back and open the .java The changes wasn't seved (potential data lost). In case of XML documents dialog "File was modified externaly. Reload it?" appears. In this manner I can e.g. open XML document twice.
Problem is when changing the root dir name, i.e. system name of the filesystem, the FileObject are made invalid that way. Problem is the support is not informed about the change neither via FileObject nor via DataObject level. Radek suggested to fix it the way listen in support also on the filesystem property change and handle it. I'll make it that probably, but don't like the solution. I think the support should be informed from data system about the upcoming change (the FO's will be invalid, thus the DO too), to be able take measures about that.
Agreed, shouldn't DataObject fire PROP_VALID from this? If so, openide/datasystems. Also would P1 be more appropriate given that there is potential user data loss?
Fixed in [trunk] Fix: openide/../loaders/OpenSupport.java [1.34] /text/EditorSupport.java [1.169] Note: It is the solution which Radek suggested. Data system has an intention to fire the PROP_VALID change after the root system name has chaned (it is not working due to some bug). But in that case is late for support, beacuse when needed to save the document, then the FO's are invalid already, thus no save is possible. FileSystem fires also vetoable change event before going to change the system name, and that would be probably nice if somehow propagated via data system to support as vetoable PROP_VALID change. That's a question. Anyway the support is needed to be informed at the time the FO's are still valid, i.e. before the actual system name change, thus allow the possible save.
verified in [nb_release34_rc1](200207232340)
Resolved for 3.4.x or earlier, no new info since then -> closing.