Доступ к файлу низкого уровня с .NET

Question

Есть ли какой-либо класс в .NET framework, который обеспечивает доступ к пути \. \ G: -. (то есть сырых объемов)?

В настоящее время мы делаем это без проблем, используя p/invoked ReadFile и WriteFile, что не является сложным для синхронного доступа, но утомительно добавлять async read/write из-за всей заботы, которую вам нужно взять на себя и обрабатывая структуру OVERLAPPED и управляя временем жизни объекта события и т. д. (т. е. все утомительные вещи, которые мы должны были бы сделать в коде Win32 ...)

Трудно доказать, что у вас есть взаимодействие с GC правильно, с любой простой методикой тестирования.

Класс FileStream содержит, без сомнения, весь этот код, абсолютно безупречный и изысканный, и использует множество внутренних помощников, которые мы не можем использовать. К сожалению, FileStream явно останавливает открытие исходного тома, поэтому мы не можем его использовать.

Есть ли что-нибудь еще в рамках, которое помогает избежать написания такого кода с нуля? Я проговорил в Reference Source, но ничего не выскочит.

Обновление - мы уже попробовали предложение ниже, чтобы избежать проверки типа пути, открыв устройство самостоятельно и передавая его в ручку. Когда мы пытаемся это, она взрывается со следующей ошибкой (отметить, что этот след проходит через contstructor из FileStream - то есть мы не получаем никакой возможности взаимодействовать с потоком на все):

System.IO.IOException: The parameter is incorrect. 

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
at System.IO.FileStream.SeekCore(Int64 offset, SeekOrigin origin) 
at System.IO.FileStream..ctor(SafeFileHandle handle, FileAccess access, Int32 bufferSize, Boolean isAsync) 
at OurApp.USBComms.UsbDevice..ctor(Char driveLetter) in 

Для справки, наш CreateFile вызов выглядит следующим образом:

var deviceName = String.Format(@"\\.\{0}:", driveLetter); 

var handle = SafeNativeMethods.CreateFile(deviceName, 
    0x80000000 | 0x40000000, 
    FileShare.ReadWrite, 
    0, 
    FileMode.Open, 
    (uint)FileOptions.Asynchronous | 0x20000000, // Last option is  'FILE_FLAG_NO_BUFFERING' 
    IntPtr.Zero); 
    if (handle.IsInvalid) 
    { 
     throw new IOException("CreateFile Error: " + Marshal.GetLastWin32Error()); 
    } 

Update3: оказывается, что (по объему ручки, во всяком случае), вы не можете назвать SetFilePointer на ручке, который был открыт с FILE_FLAG_OVERLAPPED. Это имеет смысл, поскольку SetFilePointer бесполезен в файлах, где есть какой-либо многопоточный доступ. К сожалению, FileStream, по-видимому, решил назвать это во время строительства по какой-либо причине (по-прежнему пытается отследить почему), что и является причиной сбоя.

Answer 1

Я считаю, что вы можете использовать этот constructor of FileStream, передавая предварительно открытый FileHandle как экземпляр SafeFileHandle. При этом вам удалось выполнить экземпляр FileStream, который вы можете использовать для выдачи операции асинхронного ввода-вывода.

public FileStream(SafeFileHandle handle, FileAccess access, int bufferSize, bool isAsync); 

Кроме того, когда вы планируете сделать асинхронную I/O, не забудьте установить флаг isAsnc истину. В противном случае you'll not get all the benefits of async I/O.

Answer 2

Как отметил Шрирам Сактивель (+1), вы можете передать SafeFileHandle в конструктор FileStream.

Из вашего stacktrace Я предполагаю, что вы пытались найти поток в недопустимой позиции; Необработанные диски/объем имеют специальные правила относительно позиций чтения/записи.

Например, вы не можете начать чтение диска в середине сектора (вам нужно будет прочитать/искать на кусок 512 байт). Попробуйте прочитать, например, со смещением 0, чтобы убедиться, что он работает лучше.