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 sources on different disk than my home directory. Still, for easy of accessibility I have a symlink from $HOME/src/ to the real location of the sources. I usually work with $HOME/src, but sometimes the IDE or other tools use the physical path instead. As soon as that happens the parsing and indexing of already indexed projects starts once again. The system treats the old projects as new ones and parses everything once again. Could you mark each parsed project via AuxiliaryConfiguration with some UUID and then verify whether this UUID is already parsed in the $userdir/var/cache/index*/?
If something is calling File.getCanonical*, that is a bug; do not use this call from the IDE. Reporter writes "I _usually_ work with $HOME/src" [emphasis added]. If the user uses a different path to refer to the project, IMHO that is their problem; lots of things, not just indexing, are likely to work poorly in this case.
It is not only error between chair and keyboard: ln -s /space/ $HOME/src/ cd $HOME/src/netbeans/ netbeans openide.util This call is not going to open $HOME/src/netbeans/openide.util but (/space/netbeans/openide.util). Thus if I always use $HOME/src then I get different project when opened with File/Open Project or via command line. This is because the launcher resolves all symlinks before starting NetBeans and changes directory to /space/netbeans/ so maybe the root problem is in launcher?
"If something is calling File.getCanonical*" - I don't think we do this anywhere in parsing.api. The usual workflow is: 1. get URL from ClassPath.Entry 2. root = URLMapper.findFileObject(url) 3. traverse FileObjects under root We store relative path of FOs under each root in order to remember their timestamps and in the Lucene documents. When data are loaded from Lucene we simply concatenate relative path to the root's URL, if the original FO that was indexed is needed. Tomas Zezula might know how the classpath root URLs are obtained.
If the launcher cd's to /space/netbeans in this case then yes that would be a P2 bug in the launcher.
*** Bug 194899 has been marked as a duplicate of this bug. ***
The parsing.api has no getCanonical* call. The classpath is provided by apisupport project. Jarda's case: ln -s /space/ $HOME/src/ cd $HOME/src/netbeans/ netbeans openide.util is still valid. The IDE opens second copy of openide.util with resolved symbolic links. Reassigning to launcher according to comment #4.
Sorry, we have no plans to fix this in the near future. Patches are welcome.