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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Priority|Other |Low ------- Additional Comments From [EMAIL PROTECTED] 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
