[ https://issues.apache.org/jira/browse/LUCENE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348144#comment-16348144 ]
Adrien Grand commented on LUCENE-8149: -------------------------------------- I suspect NRTCachingDirectory is a bit outdated. Those deletes should not be necessary since we never overwrite files? Extensions of {{FSDirectory}} like {{MMapDirectory}} or {{NIOFSDirectory}} would actually fail in such a case due to the {{StandardOpenOption.CREATE_NEW}} flag. > Document why NRTCachingDirectory needs to preemptively delete segment files. > ---------------------------------------------------------------------------- > > Key: LUCENE-8149 > URL: https://issues.apache.org/jira/browse/LUCENE-8149 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Erick Erickson > Assignee: Erick Erickson > Priority: Minor > > Moving over here from SOLR-11892. After getting through my confusion I've > found the following: NRTCachingDirectory.createOutput tries to delete segment > files before creating them. We should at least add a bit of commentary as to > what the pre-emptive delete is there for since on the surface it's not > obvious. > try { > in.deleteFile(name); > {{ } catch (IOException ioe) {}} > // This is fine: file may not exist > {{ }}} > If I change to using MMapDirectory or NIOFSDirectory these exceptions are not > thrown. What's special about NRTCachingDirectory that it needs this when two > of the possible underlying FS implementations apparently do not? Or is this > necessary for, say, Windows or file systems than the two I tried? Or is it > some interaction between the RAM based segments and segments on disk? -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org