The proper solution is to have your software installer disable the
indexing on the directory.
If you don't any index updates are going to be abysmally slow anyway
- and if you do a lot you will bring your clients systems to their
knees (sounds like a bad situation for them).
You should also document in the installation guide for your software
the requirements, and how certain software packages (indexers and
virus scanners) should be disable on the your software packages data
directories.
On Sep 13, 2006, at 3:37 PM, Bruce Ritchie wrote:
I'm afraid it's just not that simple. Lucene is not a server
application
as you claimed in your first reply - it's a java based search library.
Just because it's most often used on servers does not equate to it
always being used on servers for which disabling the index service
is a
reasonable thing to do. We use it in a desktop application in addition
to server applications, and being a java based application we want to
neither have to tell our clients to disable indexing, or
tortoisesvn, or
any other software they may have, nor to have to insert something into
the registry (if indeed such a thing exists).
Now, I'm not expecting lucene to be able to recover if a virus scanner
decides to mangle an index file or any other such extreme behavior,
but
I do expect it to behave correctly in the face of what I believe is a
common enough issue on a very commonly used OS. While it would be
ideal
for Java itself to workaround the issue I don't think we can expect
that
to happen for a while.
Our few choices now are to have a custom directory which has the
simple
workaround in it, patch lucene everytime we have a new release, or
ignore the issue and have customers complain. While patching lucene is
possible for me I personally think this a worthy enough issue to be
included into lucene proper.
Regards,
Bruce Ritchie
-----Original Message-----
From: robert engels [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 13, 2006 4:13 PM
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-665) temporary file access
denied
on Windows
Start -> Administrative Tools -> Windows Indexing Service -> Disable
On Sep 13, 2006, at 3:09 PM, eks dev wrote:
not promoting, "let lucene fix all Winblows problems", just
saying, if
someone has cool, simple trick in patch form, that hurts nobody,
would
be nice to accept it. Enough people burned their fingers on this one
----- Original Message ----
From: Chris Hostetter <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, 13 September, 2006 10:04:05 PM
Subject: RE: [jira] Commented: (LUCENE-665) temporary file access
denied on Windows
: While what you say is true about indexing should be disabled, that
: really doesn't solve the actual issue. Administrators of
applications
: using lucene often do not have control over the actual machine and
thus
: cannot determine what is and is not installed. Besides that,
many of
us
no, but they can st the operating params of the software they support
-- as far as i can tell based on what i've read about the issue, the
problem stems from software that does what seems to be the equivilent
of trying to open any file that has recently been closed by any other
app ... as a java library Lucene shouldn't be expected to guard
against that any more then it should be expected to guard against the
possibility of people randmoly renaming or deleting files in the
index
directory -- Lucene makes some files, and it expects to manage them
without interference from anything else -- as long as that
expectation
is documented (and i'll admit, those expectations could be documented
more thoroughly) then i think our work here is done.
Dealing withthis problem becomes the topic of a FAQ about the cause
with a pointer to a Wiki explaining the details and (*hopefully*) a
list of crazy registry hacks you can use to disable it on a per
directory basis.
(DISCLAIMER: I am not saying such hacks exist, merely that i hope
some
method of disabling this "feature" exists and if it does pointeres on
how to do so would be useful)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
