[
https://issues.apache.org/jira/browse/LUCENE-5570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960486#comment-13960486
]
Uwe Schindler commented on LUCENE-5570:
---------------------------------------
bq. The whole method isnt atomic anyway, it takes Collection of files and must
do them one by one
This was not meant to be atomic for al files. The issue here is: It is still
possible to create an empty file: if the RAF readonly open is done
successfully, then another thread deletes the file, before the RandomAccessFile
is opened for write.
I am not sure if we should backport this hack to 4.7 branch. We should better
release Lucene 4.8 on Java 7 and leave 4.7 as it is. The bug is not causing
data corrumption, it just confuses if you are debugging strange things like
issue LUCENE-5574.
> FSDirectory's fsync() is lenient
> --------------------------------
>
> Key: LUCENE-5570
> URL: https://issues.apache.org/jira/browse/LUCENE-5570
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/store
> Reporter: Robert Muir
> Fix For: 4.8, 5.0, 4.7.2
>
> Attachments: LUCENE-5570.patch, LUCENE-5570.patch,
> LUCENE-5570_java6.patch, LUCENE-5570_zerobyte.patch
>
>
> This method has a lot of problems:
> 1. it tracks 'stale files' as it writes (this seems pointless), and only
> actually fsyncs the intersection of that 'stale files' and the filenames
> passed as argument to sync(). So any bogus names passed to sync() are just
> silently ignored
> 2. if "something bad happens" (e.g. two indexwriters/dirs on the same path,
> or some other shenanigans), and the file is actually in stale files, but was
> say actually deleted on the filesystem, the underlying fsync() call will
> create a new 0-byte file and fsync that.
> In my opinion we should do none of this. we should throw exceptions when this
> stuff is wrong.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
