\nHere’s a question that came from a customer.\nThis particular example involves managed code,\nbut don’t let that distract you from the point of the exercise.\n<\/p>\n
\n\nI am trying to create a
FileStream<\/code>\nobject using the constructor that takes anIntPtr<\/code> as input.\nIn my .cs file,\nI create the native file handle usingCreateFile<\/code>,\nas shown below.\n<\/p>\n\n[DllImport(\"kernel32.dll\", CharSet = CharSet.Auto, SetLastError = true)]\ninternal static extern IntPtr CreateFile(string lpFileName,\n int dwDesiredAccess, FileShare dwShareMode,\n IntPtr securityAttrs, FileMode dwCreationDisposition,\n UInt32 dwFlagsAndAttributes, IntPtr hTemplateFile);\nIntPtr ptr1 = Win32Native.CreateFile(FileName, 0x40000000,\n System.IO.FileShare.Read | System.IO.FileShare.Write,\n Win32Native.NULL,\n System.IO.FileMode.Create,\n 0xa0000000, \/\/ FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH\n Win32Native.NULL);\n<\/pre>\n\nThen I create the
FileStream<\/code> object as so:\n<\/p>\n\nFileStream fs = new FileStream(ptr1, FileAccess.Write, true, 1, false);\n<\/pre>\n\nThe
fs<\/code> gets created fine. But when I try to do:\n<\/p>\n\nfs.Write(msg, 0, msg.Length);\nfs.Flush();\n<\/pre>\n\nit fails with the error\n“IO operation will not work.\nMost likely the file will become too long\nor the handle was not opened to support synchronous IO operations.”\n<\/p>\n
\nint hr = System.Runtime.InteropServices.Marshal.GetHRForException(e)\n<\/pre>\n\nGives
hr<\/code> asCOR_E_IO<\/code> (0x80131620<\/code>).\n<\/p>\n\nThe stack trace is as below.\n<\/p>\n
\nSystem.IO.IOException: IO operation will not work. Most likely\n the file will become too long or the handle was not opened\n to support synchronous IO operations.\nat System.IO.FileStream.WriteCore(Byte[] buffer, Int32 offset, Int32 count)\nat System.IO.FileStream.FlushWrite()\nat System.IO.FileStream.Flush()\nat PInvoke.Program.Main(String[] args)\n<\/pre>\n\nCan somebody point out what might be going wrong?\n<\/p>\n<\/blockquote>\n
\n(For those who would prefer to cover their ears and hum when\nthe topic of managed code arises,\nchange
FileStream<\/code> to\nfdopen<\/code>.)\n<\/p>\n\nThe comment on the line\n<\/p>\n
\n 0xa0000000, \/\/ FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH\n<\/pre>\n\nwas provided by the customer, and that’s the key to the problem.\nIt was right there in the comment, but the customer didn’t understand\nthe consequences.\n<\/p>\n
\nAs the documentation for
CreateFile<\/code> notes,\ntheFILE_FLAG_NO_BUFFERING<\/code>\nflag requires that all I\/O operations on the file handle\nbe in multiples of the sector size, and that the I\/O buffers also\nbe aligned on addresses which are multiples of the sector size.\n<\/p>\n\nSince you created the file handle with very specific\nrules for usage, you have to make sure that everybody who\nuses it actually follows those rules.\nOn the other hand,\nthe
FileStream<\/code> object doesn’t know about these rules.\nIt just figures you gave it a handle that it can issue normal\nsynchronousReadFile<\/code> andWriteFile<\/code>\ncalls on.\nIt doesn’t know that you gave it a handle that requires\nspecial treatment.\nAnd then the attempt to write to the handle with a plain\nWriteFile<\/code> fails both because the number\nof bytes is not a multiple of the sector size and because\nthe I\/O buffer is not sector-aligned, and you get the\nI\/O exception.\n<\/p>\n\nThe solution to this problem depends on what you are trying to accomplish.\nWhy are you passing the\n
FILE_FLAG_NO_BUFFERING |\nFILE_FLAG_WRITE_THROUGH<\/code> flags?\nAre you doing this just because you overheard in the hallway that it’s\nfaster?\nWell, yes it may be faster under the right circumstances,\nbut in exchange for the increased performance, you also have to follow\na much stricter set of rules.\nAnd in the absence of documentation to the contrary,\nyou can’t assume that a chunk of code actually adheres to your\nvery special rules.\n<\/p>\n\nLike What if two people did this?<\/i>,\nthis is an illustration of\nanother principle that many people forget to consider\nwhen working with objects they didn’t write:\nWhen you write your own code, do you do this?<\/i>\nIt’s sort of like the Golden Rule of programming.\n<\/p>\n
\nSuppose you have a function which accepts a file handle\nand whose job is to write some data do that file handle.\nDo you write your function so that it performs all its\nI\/O in multiples of the sector size from buffers which are\naligned in memory in multiples of the sector size,\non the off chance that somebody gave you a handle that was\nopened with the
FILE_FLAG_NO_BUFFERING<\/code> flag?\nWell, no, you don’t.\nYou just callWriteFile<\/code> to write to it,\nand if you want to write 28 bytes, you write 28 bytes.\nEven if you perform internal buffering and your buffer size\nhappens to be a multiple of the sector size by accident,\nyou still don’t align your I\/O buffer to the sector size;\nand when it’s time to flush the final partially-written buffer,\nyou have a not-sector-multiple write at the very end anyway.\n<\/p>\n\nIf you don’t handle this case in your code,\nwhy would you expect others to handle it in their code?\n<\/p>\n