[ 
https://issues.apache.org/jira/browse/LUCENE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14331963#comment-14331963
 ] 

Michael McCandless commented on LUCENE-6279:
--------------------------------------------

I've thought about a couple ways to fix this.

We could fix SIS to record on read that it was pre-4.0, and then on write it 
upgrades any 3.x segments.  This is kinda a big change, though, and I don't get 
why we do it today on every commit ... is there any way for a 3.x segment to 
sneak in to a 4.x SIS un-upgraded?  IW.addIndexes(Dir[]) writes upgrades .si ...

A less scary change would be to just check the SI.files() to see whether the 
.si file is in there; if it is, it was already upgraded.  Then we could remove 
the marker file entirely.

Yet another maybe even less scary option would be to keep writing the marker 
file, but check if it's already in SI.files() (instead of trying to open it 
from the filesystem) to see whether we already upgraded...

> 3.x -> 4.x .si upgrade should not be tricked by leftover upgrade marker file
> ----------------------------------------------------------------------------
>
>                 Key: LUCENE-6279
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6279
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>             Fix For: 4.10.x
>
>         Attachments: LUCENE-6279.patch
>
>
> Today when you do the first IW.commit to a 3.x index from Lucene 4.x, we go
> through a per-segment upgrade process when writing the next segments_N
> file, writing .si files for each segment if we didn't already do so.
> However, this process can be fooled by a leftover _N_upgraded.si
> file, in case the app above Lucene wasn't careful and reused a
> directory that had leftover files... I think we can make this more
> robust.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to