lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-5570) FSDirectory's fsync() is lenient
Date Fri, 04 Apr 2014 18:06:38 GMT


Uwe Schindler commented on LUCENE-5570:

Patch looks fine, only the APPEND is not needed:
{code:java}, StandardOpenOption.WRITE);

WRITE does not zero the file, to empty it you need to use TRUNCATE_EXISTING or CREATE.
APPEND is just there to initially set the file pointer.

But in any case, +1 to commit.

We can only use this with Lucene 4.7.x if we use crazy reflection and detect Java 7. Another
approach for Java 6 (4.7.x) would be to use a "non-atomic" check to first try to open the
file for read and if that works, close and reopen RW - both as RandomAccessFile).

> FSDirectory's fsync() is lenient
> --------------------------------
>                 Key: LUCENE-5570
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Bug
>          Components: core/store
>            Reporter: Robert Muir
>         Attachments: LUCENE-5570.patch, LUCENE-5570.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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message