You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by bu...@apache.org on 2002/09/09 03:36:04 UTC

DO NOT REPLY [Bug 11109] - Search lock file location should be configurable and favored over disableLuceneLocks property

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11109

Search lock file location should be configurable and favored over disableLuceneLocks property

otis@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Priority|Other                       |Low



------- Additional Comments From otis@apache.org  2002-09-09 01:36 -------
Could you please clarify the following for me:
1. Why and how would indexing corrupt a search running at the same time?
   If the index is simply being modified, this shouldn't be a problem.
   If your indexing application does more with the index, such as moving or
removing the index directory, then this would be a problem.

2. What is "indexing log file"?  Is that supposed to be "indexing LOCK file"?

So you esentially want to somehow specify a directory to which Lucene should
write various lock files, such as: luceneLockDir=/tmp ?

But would that really work on CD-ROMs?  I don't know enough about CD-ROMs, but I
think this wouldn't work for CD-ROMs, as there would be no writable file system
anywhere on CD-ROM, so lock file creation would have to be _completely disabled_
for read-only media, such as CD-ROMs.  Changing the lock file directory wouldn't
do it for CD-ROMs, would it?

I am not being sarcastic, the questions are for real :)

Regarding the 1.3 release - yes, I think it will be a while before 1.3 is released.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>