-
Notifications
You must be signed in to change notification settings - Fork 747
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ctags check prevents indexing of read-only filesystem #4574
Comments
This code is part of This effectively necessitates that source root be writable. Maybe there should be an indexer option to suppress this check, although I am generally not in favor of that because the indexer has many options already. There is also a question why does the temporary file has to be created under source root and not e.g. in system temporary directory - I suspect the thinking behind this was that this check should be as close to the indexer reality as possible. Or maybe there's some limitation of processing files outside of source root. |
Another alternative would be to test whether the source root is writable and if not, the indexer would throw the hands in despair (or shrug) and keep going without performing the test. |
I have same issue, source directory should be allowed to be read only. |
opengrok/opengrok-indexer/src/main/java/org/opengrok/indexer/util/CtagsUtil.java
Line 83 in a146392
Ran into a problem updating to the latest version of OpenGrok.
This new code tries to create a lock file in sourceRoot - but this will fail if it is a read-only filesystem. I'm not sure why the lock needs to be in source-root. This seems like a bug.
For example - I was trying to index a ClearCase Dynamic view. (Yeah I know, old-school stuff.) I wanted to index multiple VOBs - so pointed the sourceRoot to /vobs. However, "/vobs" is a read-only location - so the indexer failed due to the above line.
Is there a reason the lock file has to be in sourceRoot? I would have thought the lock needed to be associated with the index being generated.
In a separate issue - to use the index of files in a ClearCase dynamic view - the files in sourceRoot must remain visible to the OpenGrok web server. However, the OpenGrok web server runs outside the context of the dynamic view - so the files under "/vobs/someVob" are not visible. The indexing ran successfully since it was performed within the view context - but clicking on a file in the OpenGrok brower UI showed "File Not Available".
I was able to work around this by using view-extended-paths to point to "/view/myView/vobs/someVob". This way the files are still available to the OpenGrok brower UI even outside the view context. (I could have also solved this using a snapshot view instead of a dynamic view - but didn't want the hassle of the waiting for the copy-based snapshot view to download the files - or having to manage the space needed to store them.)
So - to work around both issues - I created a workspace - and put a symlink to the view-extended-paths in the workspace like so:
~/grokworkspace/someVob --> "/view/myView/vobs/someVob
Then set sourceRoot = ~/grokworkspace.
But - can the lock in sourceRoot be moved elsewhere?
Why do we need it at all? What is it protecting? (Could use a comment.)
The text was updated successfully, but these errors were encountered: