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.)
https://github.com/oracle/opengrok/blob/a146392d58254846a9ed1753d0ef8509ac80d906/opengrok-indexer/src/main/java/org/opengrok/indexer/util/CtagsUtil.java#L83
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.)