Bug 169962 - Symlinks or virtual drives break indices
Symlinks or virtual drives break indices
Status: NEW
Product: platform
Classification: Unclassified
Component: Launchers&CLI
6.x
All All
: P4 (vote)
: TBD
Assigned To: Libor Fischmeistr
issues@platform
:
: 194899 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-08-06 09:47 UTC by Jaroslav Tulach
Modified: 2014-02-10 14:15 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2009-08-06 09:47:30 UTC
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*/?
Comment 1 Jesse Glick 2009-08-27 15:43:22 UTC
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.
Comment 2 Jaroslav Tulach 2009-08-28 07:42:01 UTC
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?
Comment 3 Vitezslav Stejskal 2009-08-28 12:59:22 UTC
"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.
Comment 4 Jesse Glick 2009-08-28 14:06:40 UTC
If the launcher cd's to /space/netbeans in this case then yes that would be a P2 bug in the launcher.
Comment 5 Anton Chechel 2011-03-28 12:49:12 UTC
*** Bug 194899 has been marked as a duplicate of this bug. ***
Comment 6 Tomas Zezula 2013-07-02 16:50:57 UTC
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.
Comment 7 Jiri Rechtacek 2013-07-02 17:02:20 UTC
Sorry, we have no plans to fix this in the near future. Patches are welcome.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo