Nice! Go for it! Anyone else want to dive in and help out with other failing tests?
Michael -----Original Message----- From: news [mailto:n...@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:mgar...@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:casper...@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:n...@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: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. >>>>> >>>>> > >
