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:
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: