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.
We have setup severals java projects (java, web, ejb, ear) with netbeans 6.5.1 and occasionally we experience discrepancies between what the Netbeans UI says the contents of the java projects are, and what is actually physically stored on the file system. The netbeans IDE appears to cache its own version but does not refresh the files 100% of the time when the files are changed on the file system outside of the netbeans IDE. (We've verified this bug on several machines, where we can physiclally open the file using an external editor and see that its not the same as what netbeans says) In this instance, due to major issues with the netbeans SVN plugin, we are using TortoiseSVN (1.6.3) to manage updating and checking in files to source control. We always shut down netbeans prior to an update or commit to give Netbeans the best chance of understanding that files are being changed outside of the IDE. If this issue cannot be fixed, we at least need a way to force netbeans to update its file cache. As once it is out of sync there is no way, other than looking for compile errors, to determine if netbeans has the current state of files or not.
1) can you try nb 6.7? 2) can you attach your project, and describe steps how to reproduce it, please? Or, can you try to create some new project and try to reproduce it there? How to delete caches: 1) Exit nb 2) delete userdir/var/cache/index 3) start nb thanks.
Without requested information for long time - INVALID. We can't do anything in this case. Reporter, please add requested information and reopen issue. Thanks in advance.
Created attachment 86717 [details] Visual display of Netbean out of sync with file system
We have been trying to reproduce this consistently but its an intermittent issue, plus we are now going out of our way to avoid it due to the cost of this defect on our development time. Attached is an image showing the issue, the image shows a remote session with another machine that has just been updated from SVN, and shows the correct file, but the other netbeans session shows the old state of the file. The open text editor also shows clearly that the file system has a different file to netbeans. We experimented with netbeans 6.7 but its too unstable for our use on both Windows and Fedora, so we had to go back to 6.5.1, plus the WebSphere support seems to have disappeared. Need more work on 6.7 before its usuable. We also experimented with deleting userdir/var/cache/index but no effect. In one case we ran a verify on the EJB project which seemed to wake up netbeans and get it to re-read the file system. In all other cases we had ot to completely destroy the entire project structure and start again to be sure all files were refreshed. We see quite regularly out-of-sync issues of various kinds when we rebuild and redeploy to glassfish, so this may be related. It often will list a warning on duplicates in the component xml, or warn about dist or build files being locked (when they are not) or otherwise simply refuse to update itself without a restart of the IDE. They could be related issues, if they interfer with the internal refresh and update functions of netbeans. What we need is a test suite to be provided that verifies netbeans functions, we can try this with the project loaded to see if there is anything particular about our version of SVN Server (version 1.4.6 on freebsd) or SVN client (TortoiseSVN) that might be effecting netbeans. We also have checkstyle beans library installed that perhaps is interfering. Building a project to simulate the issue is not likely going to be possible given the intermittent nature of the issue unless we can execute a set of test cases against it. Note that we now always shutdown netbeans before doing an update, and it seems to improve things, plus we have removed the built in SVN client, which does not seem to work very well.
The refresh depends on the non native fs events which are fired only for existing FileObjects. The JDK 7.0 adds a native support which will solve this problem. *** This issue has been marked as a duplicate of 168237 ***