NightOwl888 commented on code in PR #938:
URL: https://github.com/apache/lucenenet/pull/938#discussion_r1597761803
##########
src/Lucene.Net/Util/IOUtils.cs:
##########
@@ -516,8 +519,53 @@ public static void ReThrowUnchecked(Exception th)
}
}
- // LUCENENET specific: Fsync is pointless in .NET, since we are
- // calling FileStream.Flush(true) before the stream is disposed
- // which means we never need it at the point in Java where it is
called.
+ public static void Fsync(FileSystemInfo fileToSync, bool isDir)
+ {
+ // LUCENENET NOTE: there is a bug in 4.8 where it tries to fsync a
directory on Windows,
+ // which is not supported in OpenJDK. This change adopts the
latest Lucene code as of 9.10
+ // and only fsyncs directories on Linux and macOS.
+
+ // If the file is a directory we have to open read-only, for
regular files we must open r/w for
+ // the fsync to have an effect.
+ // See
http://blog.httrack.com/blog/2013/11/15/everything-you-always-wanted-to-know-about-fsync/
+ if (isDir && Constants.WINDOWS)
+ {
+ // opening a directory on Windows fails, directories can not
be fsynced there
+ if (System.IO.Directory.Exists(fileToSync.FullName) == false)
+ {
+ // yet do not suppress trying to fsync directories that do
not exist
+ throw new DirectoryNotFoundException($"Directory does not
exist: {fileToSync}");
+ }
+ return;
+ }
+
+ try
+ {
+ // LUCENENET specific: was: file.force(true);
+ // We must call fsync on the parent directory, requiring some
custom P/Invoking
+ if (Constants.WINDOWS)
+ {
+ WindowsFsyncSupport.Fsync(fileToSync.FullName, isDir);
+ }
+ else
+ {
+ PosixFsyncSupport.Fsync(fileToSync.FullName, isDir);
+ }
+ }
+ catch (Exception e) when (e.IsIOException())
+ {
+ if (isDir)
+ {
+ Debug.Assert((Constants.LINUX || Constants.MAC_OS_X) ==
false,
Review Comment:
Yes. In Java, both JUnit and the `assert` statements throw the same
`AssertionError` type. Furthermore, in Java the asserts can be (and are) turned
on during testing. We test on Release builds, so there is no way to emulate
this with `Debug.Assert`. Some of the asserts in Lucene are *obviously* test
conditions because they keep track of state and do asserts only when asserts
are turned on. But, for the most part it is impossible to tell whether they are
intended:
1. As test conditions
2. For debugging
3. As guard clauses that can be "turned off" in production
Or any combination of the above.
Since we cannot tell what the intention is from the code, it is best to
always run the asserts during testing so we can be sure we are testing under
the same conditions as in Lucene. It also ensures end users can do the same
tests as in Lucene by turning on the asserts.
--
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: dev-unsubscr...@lucenenet.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
