> The proper solution is to have your software installer disable the > indexing on the directory.
I think you are stuck on indexing ... It's not just indexing, it can be any software that uses this windows api. > 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. I don't disagree about documenting the potential issues, indeed it's a very valid suggestion. However your suggestion to disable virus scanners I believe is not reasonable for consumers, nor is the ability to diable even possible in a lot of cases without an uninstall. I see we are not going to agree on this potential solution to this issue so I'm going to disengage from this discussion - I believe I've made my view clear enough for those who have commit abilities to take it into consideration. Regards, Bruce Ritchie 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
