Skip to content
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

New Bug? Prevents being able to index read-only filesystem #4574

Open
MoonlightCoderz opened this issue May 13, 2024 · 0 comments
Open

New Bug? Prevents being able to index read-only filesystem #4574

MoonlightCoderz opened this issue May 13, 2024 · 0 comments

Comments

@MoonlightCoderz
Copy link

inputPath = File.createTempFile("ctagsValidation", ".c", baseDir).toPath();

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant