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