Github user uschindler commented on the pull request:
https://github.com/apache/lucenenet/pull/43#issuecomment-68867010
fsync on directory is more than fsyncing all files in it (there is a
difference between syncing metadata and syncing buffers). Mike McCandless did
tests on Linux (he has a machine that he hardly switched off in a loop with
remote hardware power plug) and he tested it: When machine came up, index was
still alive (he tested Linux).
Fsync on directory flushes the file buffers of the directory *+ its
metadata*. The first one is also done by syncing metadata of a file contained,
yes that works, but the directory's metadata is not necessarily written.
Because of that it could happen that the inode of the directory is there, but
the entry in the parent directory not yet (because the directory's metadata was
not yet synced). After hard kill of machine, the fsck will report a lost+found
inode (the directory). Because of the lost dir entry, the directory itsself is
not visible in its parent.
I would still try to fsync also in windows, maybe it works at some time.
And this is what we are doing in Lucene Java - we just try the POSIX semantics,
which *may* work on Windows. So it is just best effort.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
