You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by "Michael Garski (JIRA)" <ji...@apache.org> on 2009/11/10 00:55:32 UTC
[jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
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.
RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Michael Garski <mg...@myspace-inc.com>.
Gotcha - thanks for the info!
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Monday, November 09, 2009 7:03 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Michael,
Basically, if you left the API public, as is, it allows anyone to pass a file
handle to any file. This is considered insecure. If you exposed another
public method which took a SafeHandle which represented a file and then acted
as a passthrough to the API method, then this would be insecure as well, and
it's at that point that you should basically create a new SecurityPermission
and call the Demand method on it yourself, something like:
[DllImport, SuppressUnmanagedCodeSecurity]
private static ...
public void FlushFileHandle(SafeHandle handle)
{
// Other code.
// Demand permission.
new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Demand();
// API Call.
...
}
However, because you are managing the file handle yourself, and not exposing
a method to arbitrarily make calls to the API through other public members,
then making the demand is unnecessary:
public void ManipulateFile()
{
// Do some stuff.
// Call the API. Note the handle is for a file that the instance manages,
and is expected, and
// doesn't allow for calls arbitrarily to the API.
...
}
- Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 9:16 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Nick -
Great feedback, thanks!
I'll mark it private & add the SuppressUnmanagedCodeSecurity attribute.
I don't quite follow the point of "... going to expose a public method which
accesses the API in some manner which is able to be compromised, you need to
demand the unmanaged code permission in the public method before calling the
API."
Could you elaborate on that?
Thanks,
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Monday, November 09, 2009 5:52 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Michael,
The P/Invoke declaration of the FlushFileBuffers API method should be marked
as private. You really don't want this hanging off the type publically.
Also, in addition to making it private, you should apply the
SuppressUnmanagedCodeSecurity attribute to it to prevent security stack walks
every time that this method is called (the permission stack walk will still
occur at link time though).
This is especially important when you have partially trusted
callers/restricted environments (shared hosting is a good example), because
unmanaged code might not be able to be called outright without this attribute
being applied.
If you ^do^ apply the attribute, then you really ^must^ make the method
private, and if you are going to expose a public method which accesses the API
in some manner which is able to be compromised, you need to demand the
unmanaged code permission in the public method before calling the API.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:jira@apache.org]
Sent: Monday, November 09, 2009 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush
to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
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.
RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Michael,
Basically, if you left the API public, as is, it allows anyone to pass a file
handle to any file. This is considered insecure. If you exposed another
public method which took a SafeHandle which represented a file and then acted
as a passthrough to the API method, then this would be insecure as well, and
it's at that point that you should basically create a new SecurityPermission
and call the Demand method on it yourself, something like:
[DllImport, SuppressUnmanagedCodeSecurity]
private static ...
public void FlushFileHandle(SafeHandle handle)
{
// Other code.
// Demand permission.
new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Demand();
// API Call.
...
}
However, because you are managing the file handle yourself, and not exposing
a method to arbitrarily make calls to the API through other public members,
then making the demand is unnecessary:
public void ManipulateFile()
{
// Do some stuff.
// Call the API. Note the handle is for a file that the instance manages,
and is expected, and
// doesn't allow for calls arbitrarily to the API.
...
}
- Nick
-----Original Message-----
From: Michael Garski [mailto:mgarski@myspace-inc.com]
Sent: Monday, November 09, 2009 9:16 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Nick -
Great feedback, thanks!
I'll mark it private & add the SuppressUnmanagedCodeSecurity attribute.
I don't quite follow the point of "... going to expose a public method which
accesses the API in some manner which is able to be compromised, you need to
demand the unmanaged code permission in the public method before calling the
API."
Could you elaborate on that?
Thanks,
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Monday, November 09, 2009 5:52 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Michael,
The P/Invoke declaration of the FlushFileBuffers API method should be marked
as private. You really don't want this hanging off the type publically.
Also, in addition to making it private, you should apply the
SuppressUnmanagedCodeSecurity attribute to it to prevent security stack walks
every time that this method is called (the permission stack walk will still
occur at link time though).
This is especially important when you have partially trusted
callers/restricted environments (shared hosting is a good example), because
unmanaged code might not be able to be called outright without this attribute
being applied.
If you ^do^ apply the attribute, then you really ^must^ make the method
private, and if you are going to expose a public method which accesses the API
in some manner which is able to be compromised, you need to demand the
unmanaged code permission in the public method before calling the API.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:jira@apache.org]
Sent: Monday, November 09, 2009 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush
to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
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.
RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Michael Garski <mg...@myspace-inc.com>.
Nick -
Great feedback, thanks!
I'll mark it private & add the SuppressUnmanagedCodeSecurity attribute.
I don't quite follow the point of "... going to expose a public method which accesses the API in some manner which is able to be compromised, you need to demand the unmanaged code permission in the public method before calling the API."
Could you elaborate on that?
Thanks,
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Monday, November 09, 2009 5:52 PM
To: lucene-net-dev@incubator.apache.org
Subject: RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Michael,
The P/Invoke declaration of the FlushFileBuffers API method should be marked
as private. You really don't want this hanging off the type publically.
Also, in addition to making it private, you should apply the
SuppressUnmanagedCodeSecurity attribute to it to prevent security stack walks
every time that this method is called (the permission stack walk will still
occur at link time though).
This is especially important when you have partially trusted
callers/restricted environments (shared hosting is a good example), because
unmanaged code might not be able to be called outright without this attribute
being applied.
If you ^do^ apply the attribute, then you really ^must^ make the method
private, and if you are going to expose a public method which accesses the API
in some manner which is able to be compromised, you need to demand the
unmanaged code permission in the public method before calling the API.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:jira@apache.org]
Sent: Monday, November 09, 2009 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush
to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
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.
RE: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
Michael,
The P/Invoke declaration of the FlushFileBuffers API method should be marked
as private. You really don't want this hanging off the type publically.
Also, in addition to making it private, you should apply the
SuppressUnmanagedCodeSecurity attribute to it to prevent security stack walks
every time that this method is called (the permission stack walk will still
occur at link time though).
This is especially important when you have partially trusted
callers/restricted environments (shared hosting is a good example), because
unmanaged code might not be able to be called outright without this attribute
being applied.
If you ^do^ apply the attribute, then you really ^must^ make the method
private, and if you are going to expose a public method which accesses the API
in some manner which is able to be compromised, you need to demand the
unmanaged code permission in the public method before calling the API.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:jira@apache.org]
Sent: Monday, November 09, 2009 6:56 PM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Created: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush
to Disk
FSDirectory.Sync Fix to Ensure Flush to Disk
--------------------------------------------
Key: LUCENENET-216
URL: https://issues.apache.org/jira/browse/LUCENENET-216
Project: Lucene.Net
Issue Type: Bug
Reporter: Michael Garski
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.
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Robert Jordan <ro...@gmx.net>.
Hi Michael,
Michael Garski wrote:
> Robert,
>
> Will Mono accept code with a pInvoke provided it is not executed, such
> is in the if/else you describe?
Yes. This fully backed by the ECMA spec. As long as the
p/invoke method is actually not invoked, no exception will be
thrown. So Code like this is legal:
if (somePlatform) {
someSpecificPInvokeMethod (...);
} else {
anotherPInvokeMethod (...);
}
Robert
>
> Java Lucene takes a similar approach to handling platform differences,
> such as in NIOFSDirectory support for Windows JREs.
>
> Michael
>
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
> Sent: Tuesday, November 10, 2009 8:41 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure 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
> satisfy
>> both concerns is to have a setting which indicates the Type which
> implements
>> an interface which will perform the flush on a FileStream instance.
> If the
>> setting is null, have a default implementation which resorts to the
> native
>> 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.
>
> Robert
>
>> 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 [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 10:27 AM
>> To: lucene-net-dev@incubator.apache.org
>> 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 <be...@gmail.com>
> wrote:
>>> P/invokes are unsupported in mono because the target platform dll
> only
>>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
> and
>> the
>>> iPhone OS. :(
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>>> To: lucene-net-dev@incubator.apache.org
>>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
> to
>>>> 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
> to
>>>> .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)
> <ji...@apache.org>
>>>> wrote:
>>>>> [
>>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
> ira.
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
> acti
>>>> on_12775305 ]
>>>>> Michael Garski commented on LUCENENET-216:
>>>>> ------------------------------------------
>>>>>
>>>>> Sounds like a good course of action for now. Hopefully some of the
> Mono
>>>> Lucene.Net users will see this thread and chime in.
>>>>> I'll create a new patch with conditional compilation and with
> Nick's
>>>> suggestion on the mailing list earlier regarding security.
>>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>>> --------------------------------------------
>>>>>>
>>>>>> Key: LUCENENET-216
>>>>>> URL:
> https://issues.apache.org/jira/browse/LUCENENET-216
>>>>>> 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.
>>>>>
>>>>>
>
>
>
>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Michael Garski <mg...@myspace-inc.com>.
Robert,
Will Mono accept code with a pInvoke provided it is not executed, such
is in the if/else you describe?
Java Lucene takes a similar approach to handling platform differences,
such as in NIOFSDirectory support for Windows JREs.
Michael
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
Sent: Tuesday, November 10, 2009 8:41 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure 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
satisfy
> both concerns is to have a setting which indicates the Type which
implements
> an interface which will perform the flush on a FileStream instance.
If the
> setting is null, have a default implementation which resorts to the
native
> 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.
Robert
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com>
wrote:
>> P/invokes are unsupported in mono because the target platform dll
only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
to
>>> 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
to
>>> .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)
<ji...@apache.org>
>>> wrote:
>>>> [
>>>
>>>
>
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
ira.
>>>
>
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
acti
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the
Mono
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with
Nick's
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL:
https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Michael Garski <mg...@myspace-inc.com>.
Nice! Go for it!
Anyone else want to dive in and help out with other failing tests?
Michael
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
Sent: Wednesday, November 11, 2009 3:40 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure Flush to Disk
George Aroush wrote:
> 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?
I'll do.
Robert
>
> -- George
>
> -----Original Message-----
> From: Michael Garski [mailto:mgarski@myspace-inc.com]
> Sent: Tuesday, November 10, 2009 8:01 PM
> To: lucene-net-dev@incubator.apache.org
> 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
> IO.
>
> Michael
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP]
[mailto:casperOne@caspershouse.com]
>
> Sent: Tuesday, November 10, 2009 9:41 AM
> To: lucene-net-dev@incubator.apache.org
> 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"
> as
> the dll name).
> - Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
> imagine
> .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
> call
> site. There is no reason to make that call each and every time before
> the
> 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
> checks
> anywhere in the code. If at some point Lucene.Net is going to say to
> Mono
> "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
> is
> what allows Mono to still participate, since chances are
> platform-specific
> code will be rooted out after that point.
>
> However, an abstraction like this would allow Mono to still use
> this
> functionality.
>
> - Nick
>
>
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
> Sent: Tuesday, November 10, 2009 11:41 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure
> 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
> satisfy
>> both concerns is to have a setting which indicates the Type which
> implements
>> an interface which will perform the flush on a FileStream instance.
> If the
>> setting is null, have a default implementation which resorts to the
> native
>> 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.
>
> Robert
>
>> 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 [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 10:27 AM
>> To: lucene-net-dev@incubator.apache.org
>> 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 <be...@gmail.com>
> wrote:
>>> P/invokes are unsupported in mono because the target platform dll
> only
>>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
> and
>> the
>>> iPhone OS. :(
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>>> To: lucene-net-dev@incubator.apache.org
>>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
> to
>>>> 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
> to
>>>> .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)
> <ji...@apache.org>
>>>> wrote:
>>>>> [
>>>>
>
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
> ira.
>
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
> acti
>>>> on_12775305 ]
>>>>> Michael Garski commented on LUCENENET-216:
>>>>> ------------------------------------------
>>>>>
>>>>> Sounds like a good course of action for now. Hopefully some of
the
> Mono
>>>> Lucene.Net users will see this thread and chime in.
>>>>> I'll create a new patch with conditional compilation and with
> Nick's
>>>> suggestion on the mailing list earlier regarding security.
>>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>>> --------------------------------------------
>>>>>>
>>>>>> Key: LUCENENET-216
>>>>>> URL:
> https://issues.apache.org/jira/browse/LUCENENET-216
>>>>>> 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.
>>>>>
>>>>>
>
>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Robert Jordan <ro...@gmx.net>.
George Aroush wrote:
> 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?
I'll do.
Robert
>
> -- George
>
> -----Original Message-----
> From: Michael Garski [mailto:mgarski@myspace-inc.com]
> Sent: Tuesday, November 10, 2009 8:01 PM
> To: lucene-net-dev@incubator.apache.org
> 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
> IO.
>
> Michael
>
> -----Original Message-----
> From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
>
> Sent: Tuesday, November 10, 2009 9:41 AM
> To: lucene-net-dev@incubator.apache.org
> 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"
> as
> the dll name).
> - Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
> imagine
> .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
> call
> site. There is no reason to make that call each and every time before
> the
> 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
> checks
> anywhere in the code. If at some point Lucene.Net is going to say to
> Mono
> "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
> is
> what allows Mono to still participate, since chances are
> platform-specific
> code will be rooted out after that point.
>
> However, an abstraction like this would allow Mono to still use
> this
> functionality.
>
> - Nick
>
>
> -----Original Message-----
> From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
> Sent: Tuesday, November 10, 2009 11:41 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> Ensure
> 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
> satisfy
>> both concerns is to have a setting which indicates the Type which
> implements
>> an interface which will perform the flush on a FileStream instance.
> If the
>> setting is null, have a default implementation which resorts to the
> native
>> 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.
>
> Robert
>
>> 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 [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 10:27 AM
>> To: lucene-net-dev@incubator.apache.org
>> 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 <be...@gmail.com>
> wrote:
>>> P/invokes are unsupported in mono because the target platform dll
> only
>>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
> and
>> the
>>> iPhone OS. :(
>>>
>>> Sent from my iPhone
>>>
>>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>>> To: lucene-net-dev@incubator.apache.org
>>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
> to
>>>> 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
> to
>>>> .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)
> <ji...@apache.org>
>>>> wrote:
>>>>> [
>>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
> ira.
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
> acti
>>>> on_12775305 ]
>>>>> Michael Garski commented on LUCENENET-216:
>>>>> ------------------------------------------
>>>>>
>>>>> Sounds like a good course of action for now. Hopefully some of the
> Mono
>>>> Lucene.Net users will see this thread and chime in.
>>>>> I'll create a new patch with conditional compilation and with
> Nick's
>>>> suggestion on the mailing list earlier regarding security.
>>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>>> --------------------------------------------
>>>>>>
>>>>>> Key: LUCENENET-216
>>>>>> URL:
> https://issues.apache.org/jira/browse/LUCENENET-216
>>>>>> 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.
>>>>>
>>>>>
>
>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by George Aroush <ge...@aroush.net>.
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 [mailto:mgarski@myspace-inc.com]
Sent: Tuesday, November 10, 2009 8:01 PM
To: lucene-net-dev@incubator.apache.org
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
IO.
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Tuesday, November 10, 2009 9:41 AM
To: lucene-net-dev@incubator.apache.org
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"
as
the dll name).
- Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
imagine
.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
call
site. There is no reason to make that call each and every time before
the
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
checks
anywhere in the code. If at some point Lucene.Net is going to say to
Mono
"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
is
what allows Mono to still participate, since chances are
platform-specific
code will be rooted out after that point.
However, an abstraction like this would allow Mono to still use
this
functionality.
- Nick
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
Sent: Tuesday, November 10, 2009 11:41 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure
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
satisfy
> both concerns is to have a setting which indicates the Type which
implements
> an interface which will perform the flush on a FileStream instance.
If the
> setting is null, have a default implementation which resorts to the
native
> 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.
Robert
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com>
wrote:
>> P/invokes are unsupported in mono because the target platform dll
only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
to
>>> 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
to
>>> .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)
<ji...@apache.org>
>>> wrote:
>>>> [
>>>
>>>
>
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
ira.
>>>
>
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
acti
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the
Mono
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with
Nick's
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL:
https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Michael Garski <mg...@myspace-inc.com>.
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
IO.
Michael
-----Original Message-----
From: Nicholas Paldino [.NET/C# MVP] [mailto:casperOne@caspershouse.com]
Sent: Tuesday, November 10, 2009 9:41 AM
To: lucene-net-dev@incubator.apache.org
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"
as
the dll name).
- Win32s isn't even in existence anymore, AFAIK, and if it is, I can't
imagine
.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
call
site. There is no reason to make that call each and every time before
the
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
checks
anywhere in the code. If at some point Lucene.Net is going to say to
Mono
"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
is
what allows Mono to still participate, since chances are
platform-specific
code will be rooted out after that point.
However, an abstraction like this would allow Mono to still use
this
functionality.
- Nick
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
Sent: Tuesday, November 10, 2009 11:41 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
Ensure
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
satisfy
> both concerns is to have a setting which indicates the Type which
implements
> an interface which will perform the flush on a FileStream instance.
If the
> setting is null, have a default implementation which resorts to the
native
> 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.
Robert
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com>
wrote:
>> P/invokes are unsupported in mono because the target platform dll
only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X
and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix
to
>>> 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
to
>>> .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)
<ji...@apache.org>
>>> wrote:
>>>> [
>>>
>>>
>
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.j
ira.
>>>
>
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#
acti
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the
Mono
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with
Nick's
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL:
https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
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" as
the dll name).
- Win32s isn't even in existence anymore, AFAIK, and if it is, I can't imagine
.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 call
site. There is no reason to make that call each and every time before the
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 checks
anywhere in the code. If at some point Lucene.Net is going to say to Mono
"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 is
what allows Mono to still participate, since chances are platform-specific
code will be rooted out after that point.
However, an abstraction like this would allow Mono to still use this
functionality.
- Nick
-----Original Message-----
From: news [mailto:news@ger.gmane.org] On Behalf Of Robert Jordan
Sent: Tuesday, November 10, 2009 11:41 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
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 satisfy
> both concerns is to have a setting which indicates the Type which implements
> an interface which will perform the flush on a FileStream instance. If the
> setting is null, have a default implementation which resorts to the native
> 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.
Robert
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com> wrote:
>> P/invokes are unsupported in mono because the target platform dll only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>>> 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 to
>>> .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) <ji...@apache.org>
>>> wrote:
>>>> [
>>>
>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
>>>
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the Mono
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with Nick's
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Robert Jordan <ro...@gmx.net>.
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 satisfy
> both concerns is to have a setting which indicates the Type which implements
> an interface which will perform the flush on a FileStream instance. If the
> setting is null, have a default implementation which resorts to the native
> 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.
Robert
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com> wrote:
>> P/invokes are unsupported in mono because the target platform dll only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>>> 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 to
>>> .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) <ji...@apache.org>
>>> wrote:
>>>> [
>>>
>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
>>>
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
>>> on_12775305 ]
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the Mono
>>> Lucene.Net users will see this thread and chime in.
>>>> I'll create a new patch with conditional compilation and with Nick's
>>> suggestion on the mailing list earlier regarding security.
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Sean Carpenter <st...@gmail.com>.
That may be possible in 3.0 (or whenever strict conversion from the
Java source is no longer necessary) but until then it would be nice if
2.9 ran on Mono.
Sean Carpenter
On Tue, Nov 10, 2009 at 10:59 AM, Nicholas Paldino [.NET/C# MVP]
<ca...@caspershouse.com> wrote:
> I disagree, since compile time switches seem to be unfavorable
> moving forward (based on the comments), the alternative that would satisfy
> both concerns is to have a setting which indicates the Type which implements
> an interface which will perform the flush on a FileStream instance. If the
> setting is null, have a default implementation which resorts to the native
> API call.
>
> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 10:27 AM
> To: lucene-net-dev@incubator.apache.org
> 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 <be...@gmail.com> wrote:
>> P/invokes are unsupported in mono because the target platform dll only
>> exists on Windows so there's nothing to thunk to on Linux, Mac OS X and
> the
>> iPhone OS. :(
>>
>> Sent from my iPhone
>>
>> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>>> Sent: Tuesday, November 10, 2009 7:26 AM
>>> To: lucene-net-dev@incubator.apache.org
>>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>>> 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 to
>>> .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) <ji...@apache.org>
>>> wrote:
>>>>
>>>> [
>>>
>>>
>>>
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
>>>
>>>
> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
>>> on_12775305 ]
>>>>
>>>> Michael Garski commented on LUCENENET-216:
>>>> ------------------------------------------
>>>>
>>>> Sounds like a good course of action for now. Hopefully some of the Mono
>>>
>>> Lucene.Net users will see this thread and chime in.
>>>>
>>>> I'll create a new patch with conditional compilation and with Nick's
>>>
>>> suggestion on the mailing list earlier regarding security.
>>>>
>>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>>> --------------------------------------------
>>>>>
>>>>> Key: LUCENENET-216
>>>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>>>> 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.
>>>>
>>>>
>>>
>>
>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
I disagree, since compile time switches seem to be unfavorable
moving forward (based on the comments), the alternative that would satisfy
both concerns is to have a setting which indicates the Type which implements
an interface which will perform the flush on a FileStream instance. If the
setting is null, have a default implementation which resorts to the native
API call.
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 [mailto:stcarpenter@gmail.com]
Sent: Tuesday, November 10, 2009 10:27 AM
To: lucene-net-dev@incubator.apache.org
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 <be...@gmail.com> wrote:
> P/invokes are unsupported in mono because the target platform dll only
> exists on Windows so there's nothing to thunk to on Linux, Mac OS X and
the
> iPhone OS. :(
>
> Sent from my iPhone
>
> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 7:26 AM
>> To: lucene-net-dev@incubator.apache.org
>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>> 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 to
>> .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) <ji...@apache.org>
>> wrote:
>>>
>>> [
>>
>>
>>
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
>>
>>
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
>> on_12775305 ]
>>>
>>> Michael Garski commented on LUCENENET-216:
>>> ------------------------------------------
>>>
>>> Sounds like a good course of action for now. Hopefully some of the Mono
>>
>> Lucene.Net users will see this thread and chime in.
>>>
>>> I'll create a new patch with conditional compilation and with Nick's
>>
>> suggestion on the mailing list earlier regarding security.
>>>
>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>> --------------------------------------------
>>>>
>>>> Key: LUCENENET-216
>>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>>> 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.
>>>
>>>
>>
>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Sean Carpenter <st...@gmail.com>.
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 <be...@gmail.com> wrote:
> P/invokes are unsupported in mono because the target platform dll only
> exists on Windows so there's nothing to thunk to on Linux, Mac OS X and the
> iPhone OS. :(
>
> Sent from my iPhone
>
> On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
>> Sent: Tuesday, November 10, 2009 7:26 AM
>> To: lucene-net-dev@incubator.apache.org
>> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
>> 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 to
>> .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) <ji...@apache.org>
>> wrote:
>>>
>>> [
>>
>>
>> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
>>
>> plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
>> on_12775305 ]
>>>
>>> Michael Garski commented on LUCENENET-216:
>>> ------------------------------------------
>>>
>>> Sounds like a good course of action for now. Hopefully some of the Mono
>>
>> Lucene.Net users will see this thread and chime in.
>>>
>>> I'll create a new patch with conditional compilation and with Nick's
>>
>> suggestion on the mailing list earlier regarding security.
>>>
>>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>>> --------------------------------------------
>>>>
>>>> Key: LUCENENET-216
>>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>>> 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.
>>>
>>>
>>
>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by Ben Martz <be...@gmail.com>.
P/invokes are unsupported in mono because the target platform dll only
exists on Windows so there's nothing to thunk to on Linux, Mac OS X
and the iPhone OS. :(
Sent from my iPhone
On Nov 10, 2009, at 5:11, "George Aroush" <ge...@aroush.net> 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 [mailto:stcarpenter@gmail.com]
> Sent: Tuesday, November 10, 2009 7:26 AM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
> 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 to
> .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) <jira@apache.org
> >
> wrote:
>>
>> [
> https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira
> .
> plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=12775305#acti
> on_12775305 ]
>>
>> Michael Garski commented on LUCENENET-216:
>> ------------------------------------------
>>
>> Sounds like a good course of action for now. Hopefully some of the
>> Mono
> Lucene.Net users will see this thread and chime in.
>>
>> I'll create a new patch with conditional compilation and with Nick's
> suggestion on the mailing list earlier regarding security.
>>
>>> FSDirectory.Sync Fix to Ensure Flush to Disk
>>> --------------------------------------------
>>>
>>> Key: LUCENENET-216
>>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>>> 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.
>>
>>
>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by George Aroush <ge...@aroush.net>.
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 [mailto:stcarpenter@gmail.com]
Sent: Tuesday, November 10, 2009 7:26 AM
To: lucene-net-dev@incubator.apache.org
Subject: Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to
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 to
.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) <ji...@apache.org>
wrote:
>
> [
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.
plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#acti
on_12775305 ]
>
> Michael Garski commented on LUCENENET-216:
> ------------------------------------------
>
> Sounds like a good course of action for now. Hopefully some of the Mono
Lucene.Net users will see this thread and chime in.
>
> I'll create a new patch with conditional compilation and with Nick's
suggestion on the mailing list earlier regarding security.
>
>> FSDirectory.Sync Fix to Ensure Flush to Disk
>> --------------------------------------------
>>
>> Key: LUCENENET-216
>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>> 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.
>
>
Re: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by Sean Carpenter <st...@gmail.com>.
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 to
.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) <ji...@apache.org> wrote:
>
> [ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#action_12775305 ]
>
> Michael Garski commented on LUCENENET-216:
> ------------------------------------------
>
> Sounds like a good course of action for now. Hopefully some of the Mono Lucene.Net users will see this thread and chime in.
>
> I'll create a new patch with conditional compilation and with Nick's suggestion on the mailing list earlier regarding security.
>
>> FSDirectory.Sync Fix to Ensure Flush to Disk
>> --------------------------------------------
>>
>> Key: LUCENENET-216
>> URL: https://issues.apache.org/jira/browse/LUCENENET-216
>> 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.
>
>
RE: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure Flush to Disk
Posted by "Nicholas Paldino [.NET/C# MVP]" <ca...@caspershouse.com>.
If the Mono crowd is a big concern in this case (I agree with Michael that
going to 3.5, this is the least of your concerns when it comes to the Mono
crowd), then I would recommend creating an interface with one method which
takes the FileStream and then create a default implementation which uses the
P/Invoke call.
Then, have a config section (with appropriate handler) which defines the
implementation (which is optional) or some sort of IOC mechanism where you can
get this implementation from, and then the Mono people can implement that.
- Nick
-----Original Message-----
From: Michael Garski (JIRA) [mailto:jira@apache.org]
Sent: Tuesday, November 10, 2009 12:02 AM
To: lucene-net-dev@incubator.apache.org
Subject: [jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
[
https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775285#action_12775285 ]
Michael Garski commented on LUCENENET-216:
------------------------------------------
Interesting point, but what happens to the Mono folks when we move to the 3.5
framework and utilize native .NET calls that are not supported in Mono? I
don't see the feasibility of supporting compile time switches as we move
forward.
Are there any Mono users of Lucene.Net?
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775304#action_12775304 ]
George Aroush commented on LUCENENET-216:
-----------------------------------------
Sorry, I can't answer your question with full knowledge. Beagle is written using Mono version of Lucene.Net, I don't know it's state, or what else maybe using Lucene.Net with Mono. But with 2.9, this is probably the only area we may have to put in conditional compilation code to make 2.9 usable by Mono with very little effort for us and for Mono.
When we start with 3.0, we can engage Mono folks on this subject, and we may end up saying "sorry, we have to move on".
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777643#action_12777643 ]
George Aroush commented on LUCENENET-216:
-----------------------------------------
Nice work Mike and Robert. I'm ready to take this patch, but a question before I do so. Is there any reason why the new methods added to FSDirectory.cs, which are: IsUnix, IsWindows, and Sync can't be moved to SupportClass? The reason is to keep the code in par with java Lucene as much as possible. I can do it when I'm apply the patch.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep.patch, 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.
[jira] Updated: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Robert Jordan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Jordan updated LUCENENET-216:
------------------------------------
Attachment: FSDirectory-Sync-PlatformIndep.patch
The patch implements Sync() for Win-API and Unix.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep.patch, 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.
[jira] Updated: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Robert Jordan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Jordan updated LUCENENET-216:
------------------------------------
Attachment: (was: FSDirectory-Sync-PlatformIndep.patch)
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep2.patch, 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Robert Jordan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777711#action_12777711 ]
Robert Jordan commented on LUCENENET-216:
-----------------------------------------
I'm on it.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep.patch, 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Michael Garski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775305#action_12775305 ]
Michael Garski commented on LUCENENET-216:
------------------------------------------
Sounds like a good course of action for now. Hopefully some of the Mono Lucene.Net users will see this thread and chime in.
I'll create a new patch with conditional compilation and with Nick's suggestion on the mailing list earlier regarding security.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777035#action_12777035 ]
George Aroush commented on LUCENENET-216:
-----------------------------------------
Do we have a final resolution on this or are we putting this off 2.9? There was a good amount of discussion on this one in the mailing list, so it didn't get captured here.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Resolved: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
George Aroush resolved LUCENENET-216.
-------------------------------------
Resolution: Fixed
Committed. Thanks Robert, nicely done!
One small change I made is moved the test-case code to TestSupportClass.cs and renamed the test name. This is so we keep the test-case count consistent with Java Lucene.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep2.patch, 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "George Aroush (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775280#action_12775280 ]
George Aroush commented on LUCENENET-216:
-----------------------------------------
Question: how will this affect the Mono project? I'm asking about those 2 lines:
[System.Runtime.InteropServices.DllImport("kernel32")]
public static extern int FlushFileBuffers(Microsoft.Win32.SafeHandles.SafeFileHandle SafeFileHandle);
Will this cause run-time issues when Lucene.Net is compiled using Mono to run under Linux? I'm sure it will unless if Mono has some magic to deal with it. My suggestion is we make this code conditional compiled. That is, if LUCENE_NET_MONO we use this new code, otherwise we don't. For the Mono folks, they have to define it.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Michael Garski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776307#action_12776307 ]
Michael Garski commented on LUCENENET-216:
------------------------------------------
I will circle back to this one and finish it off after finishing up with the indexable binary strings.
I'll implement with a platform setting and an if/else at this time. I like Nick's idea of abstracting platform-specific items through interfaces, but that can be altered at a later time.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Updated: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Robert Jordan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Robert Jordan updated LUCENENET-216:
------------------------------------
Attachment: FSDirectory-Sync-PlatformIndep2.patch
FSDirectory-Sync-PlatformIndep2.patch moves invariant code to SupportClass.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep2.patch, 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.
[jira] Updated: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Michael Garski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Garski updated LUCENENET-216:
-------------------------------------
Attachment: FSDirectory.Sync.patch
Here is the patch. Fairly small change.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Michael Garski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775285#action_12775285 ]
Michael Garski commented on LUCENENET-216:
------------------------------------------
Interesting point, but what happens to the Mono folks when we move to the 3.5 framework and utilize native .NET calls that are not supported in Mono? I don't see the feasibility of supporting compile time switches as we move forward.
Are there any Mono users of Lucene.Net?
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "hammy72@ntlworld.com (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776401#action_12776401 ]
hammy72@ntlworld.com commented on LUCENENET-216:
------------------------------------------------
please take me off the mailing list.
Thank you
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> 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.
[jira] Commented: (LUCENENET-216) FSDirectory.Sync Fix to Ensure
Flush to Disk
Posted by "Michael Garski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENENET-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777357#action_12777357 ]
Michael Garski commented on LUCENENET-216:
------------------------------------------
Nice one Robert - love the addition of the Mono-specific flush call :)
One thing - would putting the static properties for the platform somewhere else be more appropriate? I'm sure this won't be the last time a platform switch will be needed. Java Lucene uses the Util.Constants class for this, and I feel we should do the same.
> FSDirectory.Sync Fix to Ensure Flush to Disk
> --------------------------------------------
>
> Key: LUCENENET-216
> URL: https://issues.apache.org/jira/browse/LUCENENET-216
> Project: Lucene.Net
> Issue Type: Bug
> Reporter: Michael Garski
> Attachments: FSDirectory-Sync-PlatformIndep.patch, 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.