lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George Aroush" <>
Subject RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Date Wed, 11 Nov 2009 05:05:32 GMT
For 2.9, we have just this one place in Lucene.Net code that requires
special attention for Mono support.  My vote goes for a quick and simple
solution.  Who is up for providing a patch?

-- George

-----Original Message-----
From: Michael Garski [] 
Sent: Tuesday, November 10, 2009 8:01 PM
Subject: RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure Flush to Disk

I really like the idea of breaking out platform-specifics to an
interface.  In that way users of Mono or any other platform can
implement their own interface if one of the provided implementations
does not meet their needs.  This may not be the best example, but if
Mono on Linux needed one implementation, OSX another, and Solaris
another, XBOX another (good example BTW :) ) then those users can whip
up their own.

Now for what is 'platform-specific'... IMHO I see it not as
language/runtime version issues but underlying OS differences such as


-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] []

Sent: Tuesday, November 10, 2009 9:41 AM
Subject: RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure Flush to Disk

	I don't have a problem with that.  I'd prefer to see the check
be a check 
against != (PlatformID.Win32NT || PlatformId.Win32Windows):

- I'm not sure how XBOX would make the P/Invoke call.
- WinCE requires a separate P/Invoke declaration (to using "Coredll.dll"
the dll name).
- Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
.NET 2.0 apps are running on it.

	However, with your approach, I prefer to see the result of the
boolean check 
above placed into a readonly static variable and then check that at the
site.  There is no reason to make that call each and every time before
call to the API.

	As for too much abstraction, I disagree, given that is exactly
what is done 
for compression support and I'd prefer not to see platform specific
anywhere in the code.  If at some point Lucene.Net is going to say to
"sorry, we have to move forward" (and that was hinted at when commits
are in 
sync with Java, with a desired timeline of 2.9 or 3.0), then this option
what allows Mono to still participate, since chances are
code will be rooted out after that point.

	However, an abstraction like this would allow Mono to still use

		- Nick

-----Original Message-----
From: news [] On Behalf Of Robert Jordan
Sent: Tuesday, November 10, 2009 11:41 AM
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Flush to Disk

Nicholas Paldino [.NET/C# MVP] wrote:
> 	I disagree, since compile time switches seem to be unfavorable
> moving forward (based on the comments), the alternative that would
> both concerns is to have a setting which indicates the Type which
> an interface which will perform the flush on a FileStream instance.
If the
> setting is null, have a default implementation which resorts to the
> API call.

Too much abstraction. It could be as simple as this:

if (Environment.OSVersion.Platform == PlatformID.Unix ||
     Environment.OSVersion.Platform == PlatformID.MacOSX) {
     // do nothing for know
} else {
     FlushFileBuffers (...);

I'll provide a patch for Mono once this or a similar
code is committed.


> 	Then the Mono crowd can then write their own hook for this
> functionality and set the setting in the config file.
> 		- nick
> -----Original Message-----
> From: Sean Carpenter []
> Sent: Tuesday, November 10, 2009 10:27 AM
> To:
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure Flush to Disk
> I think conditional compilation will be the solution for anything that
> requires P/Invokes (at least for now).
> Sean Carpenter
> On Tue, Nov 10, 2009 at 10:07 AM, Ben Martz <>
>> P/invokes are unsupported in mono because the target platform dll
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
> the
>> iPhone OS. :(
>> Sent from my iPhone
>> On Nov 10, 2009, at 5:11, "George Aroush" <> wrote:
>>> This is good to know.  How about code like this:
>>>   [System.Runtime.InteropServices.DllImport("kernel32")]
>>>   public static extern int
>>> FlushFileBuffers(Microsoft.Win32.SafeHandles.SafeFileHandle
>>> SafeFileHandle);
>>> Will this work with Mono?
>>> -- George
>>> -----Original Message-----
>>> From: Sean Carpenter []
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To:
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
>>> Ensure Flush to Disk
>>> I've done some work with Lucene.Net on Mono, so keeping it running
>>> there is important to me.  As for issues related to the future move
>>> .Net 3.5, Mono has support for 3.5 including LINQ, so that shouldn't
>>> be a concern.  The P/Invokes are the biggest concern to me.
>>> Sean Carpenter
>>> On Tue, Nov 10, 2009 at 12:44 AM, Michael Garski (JIRA)
>>> wrote:
>>>>   [
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>> Sounds like a good course of action for now.  Hopefully some of the
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>                Key: LUCENENET-216
>>>>>                URL:
>>>>>            Project: Lucene.Net
>>>>>         Issue Type: Bug
>>>>>           Reporter: Michael Garski
>>>>>        Attachments: FSDirectory.Sync.patch
>>>>> DIGY and Doug discussed this issue during the 2.9 port, and this
is a
>>> patch to give 2.9 the expected behavior of actually ensuring the OS
>>> flushes
>>> it's buffers to disk.  DIGY suggested using the kernel32 method
>>> FlushFileBuffers, and after investigation he was correct!
>>>  FileStream.Flush
>>> doesn't do that - the OS could still be caching it.
>>>> --
>>>> This message is automatically generated by JIRA.
>>>> -
>>>> You can reply to this email to add a comment to the issue online.

View raw message