NightOwl888 commented on issue #933: URL: https://github.com/apache/lucenenet/issues/933#issuecomment-2019860802
@paulirwin - I agree. If it is possible to mimic an fsync in .NET, we should also do that. This may be the root cause of #894. As for the history, this goes back to this conversation: https://lists.apache.org/[email protected]:2017-1 and anything from Vincent after that point. He helped pull what we had in the Store namespace together and make it more stable and efficient. It was around this time when we nix'd fsync, but at that point .NET Core support was still in the works and we had no way to test on anything but Windows. So, the benefit of supporting fsync seems more clear now. Whether providing fsync is feasible in .NET is another question. We had to drastically alter the way file locking works in order to provide support in .NET and I am not sure whether that is also relevant to this conversation. I haven't gone over the benchmarks in detail, but adding the `FileOptions` also sounds like a good idea provided it is tested thoroughly. Not sure whether `FileOptions.Asynchronous` is going to shoot us in the foot. Also, we would need to review to make sure that the same options make sense for all callers. If not, we may need to consider a way to change the options on the public or internal APIs. Based on the LUCENE-5588 comment, it also seems that supporting that JRE crash test (ACID) on Windows is probably not possible. It would probably be worth a try to disable that test on Windows (and remove the `[AwaitsFix]` attribute) to see whether it always succeeds on Linux and macOS. It would have to be tested dozens of times to be sure though - it rarely fails. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
