: > 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 environment. 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? -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
