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.
I have data object with one primary and one secondary file. When I create these file just before call of DataObject.find it returns sometimes incorrect data object (DataFolder or DefaultDataObject instead of my expected data object). Workaround should be to enclose creating of files in atomic action block.
One example from XML workspace layout. Use user dir from issue #15752 (user.zip). Take fresh IDE and redirect user dir to directory you obtain by uncompressing user.zip. If NB 3.2.1 project is opened deserialization if performed and whole window system is then saved to XML. In this case primary and secondary files are created for modes and then DataObject.find() is called immediatelly. Code is in org.netbeans.core.windows.layers.WorkspaceData around line 535. We use atomic action for creating files here. It makes things better. So if you remove atomic action block it should happen more often. It logs: "No save cookie for data obj ..." when it happens because DataFolder and DefaultDataObject returned from find do not have save cookie. User dir contains for projects, when old project is opened for the first time it is converted and during that problem happens sometimes. I recommend to remove atomic action block and switch among project. When you open all old projects it is necessary exit ide clean user dir, copy old user dir to you work dir and try again till problem arises. If you have any trouble I can try to reproduce it.
Note: Folder is primary file, data file with extension is secondary file. I do not know if it makes any difference to call find on primary or secondary file. In this case both (PF and SF) are created.
Vita, if you want me to work on this one, assign it to me.
Jesse, thanks for your help. I am not sure how this one can be fixed easily. Recognition of new DOs is done asynchronously in FolderList refresh task, thus DO.find can get different results depending on the state of folder recognition. The safe way how to create files for MultiDO is to use FileSystem.runAtomicAction and to create secondary files first and primary file as the last one. This way DataSystems users can be sure that their loader has all info neccessary to recognize proper MultiDO. Several DefaultDataObjects may be created by the way, but they will die soon. This is my explanation (may not be 100% correct) and I seem it to be bigger architectural problem then simple bug. Reassigning to Jesse.
CCing myself.
Working on tests.
As Vita says, without a formal synchronization mechanism for the folder recognizer, it is probably not possible to really fix this problem. However I have made some tests which try to mix file creation, deletion, and recognition at different time intervals, using different code policies (see DataLoaderTest). The upshot is that some policies fail frequently with race conditions; some fail once in a while; some seem reliable. The code you currently have in WorkspaceData is the *least* reliable I could find (scenario #5 in the test). You should use the atomic action as you do; create the secondary file first as you do; but then you should recognize the primary, not the secondary, file (#6), or you are very likely to get a DefaultDataObject instead. At least according to this test, which is of course an artificial situation. Note there is also a possible race condition if the primary file already exists on disk and you are only creating the secondary, or if both already exist; best to create both, starting with the secondary. If you get the wrong result, I might recommend waiting a fraction of a second (yuck!) and trying again.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.