lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <>
Subject Re: Unauthorized Access Exceptions in tests
Date Mon, 05 Jan 2015 15:04:49 GMT
I believe the code was commented out because it doesn't seem like it is
needed on Windows, although my understanding of that could be wrong. I've
used code with the sync stuff commented out in apps in
production for a couple years and no issues.

However, that doesn't mean that there can't be a possible issue, especially
if you factor in Mono on Linux/OS X with different filesystems. Does anyone
know the actual purpose of the fsync code in Java Lucene? Is recreating it
even needed with System.IO?

Paul Irwin
Lead Software Engineer

Cell: 863-698-9294

On Mon, Jan 5, 2015 at 8:56 AM, Laimonas Simutis <> wrote:

> Tests occassionally fail with Unauthorized access exception with stack
> trace pointing here:
> To understand the full issue, you can see how it is being called from here:
> Note how it first fsyncs the files and then if there were any that were
> fsynced, it fsyncs a directory containing the files. Directory part is the
> one that is causing the problems.
> The issue is that fsync implementation in the IOUtils is using FileStream
> class to flush both files and directories. Doing so for directories throws
> Access Denied exception, always. FileStream class cannot be used to "open"
> directories.
> Trying to think how to fix this. The simplest one is to catch Access Denied
> thrown and ignore it. You can see how the existing implementation does this
> for IOException catch branch. if dir is true, the IOException is ignored
> and method passes. That would be the simplest thing to do to get the tests
> passing. Heck, even ignore the whole fsync if it is for directory.
> I do think the complete approach would involve falling back to native
> functions (CreateFile for Windows to get directory's handle:
> or equivalent in non Windows) and then call FlushFileBuffers or equivalent
> in non-Windows. It is kind of what is present in FileSupport class (
> )
> but not fully implemented. It seems like IOUtils tried to use FileSupport
> Sync implementation but it was commented out. Does anybody know anything
> about that? Why it was commented out, etc?
> Looking for advice here on how to proceed. There is a good number of tests
> failing this way so it would be a nice issue to take care off. Perhaps go
> with the simple route and mark the full implementation for TODO?
> Laimonas

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message