uschindler commented on issue #14334: URL: https://github.com/apache/lucene/issues/14334#issuecomment-2771580012
> There was no crash, that's the problem. You wrote a file, then opened it again for reading and it's corrupted, and there was no IO error reported. > > As I said, if you close a file without fsyncing, write-back errors con't be reported to the writing process. The IO error might be a network glitch on your SAN, which doesn't automatically crash the whole system. This is a general problem and does not have anything to do with fsync. If this is really a problem, then every application everywhere and everytime would need to call fsync on close. So it would need to be the default in the OS. About temporary files: If a temporary file in the lucene index is corrupted then lucene will bail out, which is something that could always happen. There are no guarantees, because Lucene also caches documents in memory before writing, it may or may not create a tempoirary file! In Lucene, if you want to persist the index, you need to commit. After commit, no temporary files are in use. If a temporary file was corrupt before, the commit fails. So in short: No problem. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
