You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
This code is part of canProcessFiles() method which is used to check whether Universal ctags is able to process files in the source root (#4125). This check happens in the beginning of the indexing to provide fail fast behavior - discovering that ctags is not working properly during the second stage of the indexing is a bit too late.
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.
vladak
changed the title
New Bug? Prevents being able to index read-only filesystem
ctags check prevents being able to index read-only filesystem
Jul 31, 2024
vladak
changed the title
ctags check prevents being able to index read-only filesystem
ctags check prevents indexing of read-only filesystem
Aug 15, 2024
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.
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: