Well, not like one would expect (maybe that's an understood behavior?)
$ mkdir dir
$ echo "hello" > dir/foo.c
$ ln -s dir/foo.c foo.c
$ ls -l foo.c
lrwxrwxrwx 1 sbelmon sbelmon 9 Aug 11 16:25 foo.c -> dir/foo.c
$ wc foo.c 1 1 6 foo.c
wc thinks it's there indeed. But cscope doesn't, so it doesn't like
some cscope.files that make complete sense.
$ find . -name "*.c" | tee cscope.files
./dir/foo.c
./foo.c
$ cscope -b
cscope: cannot find file foo.c
Huh?
Easy enough: accessible_file() uses lstat(). Maybe there's some deep
reason, but it's not clear to me: The next thing we do is check that
it's a plain file (not a directory, not a socket, etc.) -- so if
stat() says "it's REG (after chasing the symlinks)", we know we'll be
able to fopen() it...
--- src/dir.c~ 2009-04-10 07:37:36.000000000 -0700
+++ src/dir.c 2010-08-11 16:29:53.000000000 -0700
@@ -651,7 +651,7 @@
if (access(compath(file), READ) == 0) {
struct stat stats;
- if (lstat(file, &stats) == 0
+ if (stat(file, &stats) == 0
&& S_ISREG(stats.st_mode)) {
return YES;
}
Well, of course, we're assuming the tree stays put under us (one would
want to just fopen() and see what happens), but that's another story.
The CVS tip seems to have the same problem.
--
Stephane Belmon <sbel...@gmail.com>
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Cscope-devel mailing list
Cscope-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cscope-devel
