lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dejan Nenov" <>
Subject RE: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Date Wed, 13 Sep 2006 22:32:33 GMT
I concur with Hoss - a default to immediate exception throwing and optional
implementation for Windows would server everyone best I think.


-----Original Message-----
From: Chris Hostetter [] 
Sent: Wednesday, September 13, 2006 2:57 PM
Subject: Re: [jira] Commented: (LUCENE-665) temporary file access denied on

: > While it's very tempting to take the attitude of "it's Microsoft's
: > fault for exposing this API" or "it's that software's fault for using
: > this API", doing so will only hurt our users: they either suffer (at
: > best), or find some other search software to use (at worst?).

: If this can be fixed/worked-around in a manner that does not penalize
: users w/o this problem, then that's what we should do.

I agree in spirit, but the caveat to that is that if we silently work
arround the problem at a very low level, it can lead to situations were
lucene is constaintly waiting and retrying every single operation -- which
may lead people to assume Lucene itself is slow just because of their

An exception thrown can be researched and documented in such a way that
application developers can fix it themselves.  An exception that is silently
worked arround with a performance penalty will be a ghost in the machine --
which can do more harm to the Lucene User community at large?

Looking at the patch, I can't help but wonder if this is motivation enough
to create a new WindowsFSDirectory implementation, which attempts to work
arround any/all issues of windows filesystems, with documentation clarifying
what it does and what the performance impacts are?


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message