[
https://issues.apache.org/jira/browse/LUCENE-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13098981#comment-13098981
]
Shai Erera commented on LUCENE-3237:
------------------------------------
It could be, and generally I think that it makes sense. Only the Java
documentation is not so explicit about it - I wish it was. Because if Java was
explicit, it would mean we wouldn't need to wonder what do the "man pages" say
about this on Windows, AIX etc.
If others think that it makes sense that sync() affects all existing buffers,
then I don't mind if we close that issue. We haven't seen any problems with
this implementation so far, so it kinda reassuring ...
> FSDirectory.fsync() may not work properly
> -----------------------------------------
>
> Key: LUCENE-3237
> URL: https://issues.apache.org/jira/browse/LUCENE-3237
> Project: Lucene - Java
> Issue Type: Bug
> Components: core/store
> Reporter: Shai Erera
> Fix For: 3.4, 4.0
>
>
> Spinoff from LUCENE-3230. FSDirectory.fsync() opens a new RAF, sync() its
> FileDescriptor and closes RAF. It is not clear that this syncs whatever was
> written to the file by other FileDescriptors. It would be better if we do
> this operation on the actual RAF/FileOS which wrote the data. We can add
> sync() to IndexOutput and FSIndexOutput will do that.
> Directory-wise, we should stop syncing on file names, and instead sync on the
> IOs that performed the write operations.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
