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:[email protected]]
Sent: Monday, November 09, 2009 6:56 PM
To: [email protected]
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.
smime.p7s
Description: S/MIME cryptographic signature
