lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4190) IndexWriter deletes non-Lucene files
Date Wed, 04 Jul 2012 13:30:35 GMT


Shai Erera commented on LUCENE-4190:

I also raised an eyebrow when I read this comment. Many of the lucene+facet deployments that
I know of store the taxonomy index as a sub-directory of the search index. Also, we've been
storing other files in the index directory too ... this new feature will affect such existing

I think it makes sense to change IW behavior to only delete files that start with _. It's
a reasonable requirement IMO.

While I don't know the nature of this change, I can assume it's related to IW not knowing
which files to delete when a segment is no longer needed, because Codecs can pick their own
file names. If we had an instance which kept track of all files that were created, e.g. every
Codec would register the files there (if it wants to protect from their deletion), would make
the decision of which files to delete easier?
> IndexWriter deletes non-Lucene files
> ------------------------------------
>                 Key: LUCENE-4190
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.0
> Carl Austin raised a good issue in a comment on my Lucene 4.0.0 alpha blog post:
> IndexWriter will now (as of 4.0) delete all foreign files from the index directory. 
We made this change because Codecs are free to write to any files now, so the space of filenames
is hard to "bound".
> But if the user accidentally uses the wrong directory (eg c:/) then we will in fact delete
important stuff.
> I think we can at least use some simple criteria (must start with _, maybe must fit certain
pattern eg _<base36>(_X).Y), so we are much less likely to delete a non-Lucene file....

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message