When cscope is run with "-R -q", it (re)builds an inverted index in addition to the normal index. This inverted index appears to go bad with respect to a mapping to file names, if the source directory contains unreadable source files. One source of such files are emacs symlink "locks" that point to nonexistent places, although other errors can also occur. What happens then is that an interactive search using the inverted index identifies the wrong file names with hits. It is as if the unreadable files did get an ID reserved in one cscope table, but not in others. One can see this effect if one makes a toy directory with a few .c files, and a symlink like "ln -s /NONEXISTENT file.c". With "cscope -R" alone, the file.c nonexistence will be noted during index rebuild, but will not result in corrupted data. With "cscope -R -q", the hits can point to the wrong file.
I doubt the behavior is in any way dependent on the OS version. I'm pretty sure it's some smallish error handling bug in build.c someplace. Both invocations note the inaccessibility of the symlink during parse. The difference I saw was that during interactive use of a database built with "-q" also, the filename listed for a search hit was incorrect.
Ah, you're right, I've reproduced it now. I'll get it fixed ASAP. Thanks
I've checked a patch into CVS for this bug, and its ready for the next QA build.
BTW the new patch is not quite enough. Consider the case of an ordinary read error, like if a source file was "chmod 000". I believe the symlink example is just a special case of a more general problem.
The same problem does recur with the "chmod 000" real file. Re what the check should be... I don't know exactly. I would follow the code to see how it handles parsing errors in general - what control flow ends up in printing that error message to the screen. There I'd modify the code in order to make the index exclude the problematic file.
I think I found the root cause of this problem. It would appear that searches in cscope rely on both the srcfiles array, which is a list of all the files found in a source tree, and the cscope database, which indexes all the symbols in the files listed in srcfiles. The problem is, that a minimal entry is required in the database for every file, even if it contains no symbols. The problem is that unreadable files (as described in this bug), don't get that minimal entry (which is added in the crossref() function), and as such the database index into the srcfiles array becomes skewed. I'm proposing a fix for this in the public forum right now, and as soon as I get feedback/acceptance on it, I'll check in the fix here.
The public list is fairly quiet at the moment on this. I like the fix though, and its fairly straightforward, so I've checked it in. If there is any future disagreement on this fix upstream, I'll make the appropriate correction at that time, although I don't think there will be any argument.