SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: cvavruska on August 16, 2019, 12:21:49 AM
-
I am working with a project on a case insensitive file system (jfs). I have about 10 .c files. When I cross reference a tag it shows the file.c and file.C. How do I get it to only show the file that was added to the project?
In the future I might have .C files so I don't restrict it to only .c files
-
That's curious. If you go to Tools -> Tag Files, and select your workspace/project tag file, does the file list have both versions of the file name? If so, re-building the tag file should repopulate it with just the files as they're defined in your project file.
That would leave the mystery of how both names got in the database. From what I've read, it sounds like case insensitive JFS preserves case, so I don't think any of the normalization steps we do for filenames could change the case from what's listed in the project file.
-
When I got to tools->tag files it only shows the actual file names (ie. file.c, file.h) When I rebuild it gives the same results.
-
There is some logic in references to look for references in associated files. For example, if you do a search for a symbol declared in file.h, it will try to add file.c to the list of files to search for references in. Since you are on a case-sensitive OS, but working with a case-insensitive file system, when it cycles through the list of associated file extensions, it's going to find a match for both "file.c" and "file.C". Without actually comparing i-nodes, being on a case-sensitive OS, we just assume those are two different files and include them in the list. This could be better, but it would be a lot of effort for a special case.
-
So you are saying it is a bug that most likely wont be fixed even if I did upgrade to 2019?
-
Do you mean the references search includes non workspace files? That seems a little surprising, though I'm not sure why anyone would have two files with the same name in the same folder.
-
@cvavruska: It is a bug, but it is not worth fixing at this point, as the result is only a minor inconvenience in a case where you are using a case-insensitive file system on Linux (a very rare case).
@Graeme: It can if there is an associated file in the same directory, which is not in your workspace (and probably should have been). That part is not a bug.