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:n...@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:stcarpen...@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 <benma...@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" <geo...@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:stcarpen...@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) <j...@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. >>>> >>>>
