lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Date Wed, 13 Sep 2006 21:03:39 GMT
Bruce Ritchie wrote:

> No, I've just seen this jira issue because of your email - my last
> investigation of the issue was last year for which I personally did not
> uncover the cause nor a simple solution to the issue. Instead, we took
> the severe approach to just rebuild the index which itself causes issues
> (not technical, more customer satisfaction).

This is precisely why I publicized this sneaky issue in the first
place (and many thanks to Doron for actually tracking it down!!):
people who hit it never can get to the bottom of it, and then just
suffer through the consequences or stop using Lucene entirely.

Nobody would even know to uninstall TortoiseSVN (or one of the many
other software packages that may cause this).

At least Ant and SVN (the server) have taken this same attitude (of
trying to work around temporary file rename failures).

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?).

The fact that this is an OS level API only means that more software
over time is going to use it.  So, maybe you have Lucene working fine
now, but suddenly on installing new software XYZ you're gonna be
hitting these intermittant errors.  Or worse, your users, maybe a
million installed desktops, will start hitting those errors...

Furthermore, because Lucene has such a wonderfully simple
architecture, it's not so hard to change it to never do any file
renaming (I will try this with the lockless changes which already do
far less renaming).  Meaning, if this is such a simple change for
Lucene with no other consequences, why not do it to prevent all these
problems?  The less Lucene can assume about the filesystem it's using,
the more portable it will be.

I agree that Lucene should not and can not recover from catastrophic
things (like virus checker deciding a .fnm file contains a virus!),
but this one seems very much like a low hanging fruit.


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

View raw message