Mailing List Archive

Lucene 1.2 and directory write permissions?
I've been porting our application to use the 1.2 release candidate 1 build
and now have a problem opening searchers on our existing indexes. I get a
Permission Denied exception... our permissions are set up to allow reading
of the directory and contained files during a search, but not writing.

I know there was some lock-file code added to the latest release, but it
doesn't seem like this should be causing a problem for a searcher that is
read only.

Does anyone have any ideas on what the problem might be? Should I be
opening the searcher in a different way?

Any help would be appreciated,
Dave Snyder
RE: Lucene 1.2 and directory write permissions? [ In reply to ]
> From: Snyder, David [mailto:dsnyder@netgenics.com]
>
> I've been porting our application to use the 1.2 release
> candidate 1 build
> and now have a problem opening searchers on our existing
> indexes. I get a
> Permission Denied exception... our permissions are set up to
> allow reading
> of the directory and contained files during a search, but not writing.

Hmm. That is a problem. The reader now creates a lock file while it is
opening the index to keep a writer process from deleting files while they're
being opened. When opening an index the reader must first read the list of
files to open, then open them. If between reading the list and opening a
file that file were to disappear, then the open would fail. This was the
longstanding race condition that is fixed by the lock files. A writing
process will now wait for the reader to open all of the files before
updating things.

Perhaps we should instead write lock files in a subdirectory of the index
named "locks". You could make that directory read/write, but make the
parent read-only. Alternately, we could have an flag that turns off the use
of lock files, for those who know that there is no other process that is
potentially simultaneously updating the index. Which approach would folks
prefer?

Doug
Re: Lucene 1.2 and directory write permissions? [ In reply to ]
> ...
> Perhaps we should instead write lock files in a subdirectory of the index
> named "locks". You could make that directory read/write, but make the
> parent read-only. Alternately, we could have an flag that turns off the use
> of lock files, for those who know that there is no other process that is
> potentially simultaneously updating the index. Which approach would folks
> prefer?

If wanted to store an index on a read-only medium then would need to
be able to turn off lock file usage altogether, or specify an alternate
directory that wasn't part of the index tree. Not something I've
ever needed to do, but someone might want to sometime.

Could the lock creation code check for write access to the index
directory and just skip the locks if can't create the file? If
the index is read-only then nothing is going to be updating it
anyway.



--
Ian.
ian.lea@blackwell.co.uk