Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info:

Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 1  
09 Nov 17 22:39
Jorgen Lundman
Join Date: 09 Nov 2017
Posts To This List: 1
GPT EFI Partitions

Hello list, Problem: When attaching a ZFS pool disk to Windows, it fails to recognise the partitions used with ZFS. The default layout being MBR protected EFI partition table. If opening the \PhysicalDrive1 by hand, the calls to IOCTL_DISK_GET_PARTITION_INFO or IOCTL_DISK_GET_DRIVE_GEOMETRY_EX will only see the MBR partition. Likewise, FindFirstVolume() / FindNextVolume() will not iterate the partitions that I am interested in. Since, of course, nothing has created the \Volume{} entries needed. Currently I use libefi, and read the EFI partition table myself, and a temporary hack to access the data. It would be nice however, if I can make it support GPT/EFI partition table, and have the \Volumes{} created and everything can follow standard Windows methodology. Solution? I have been reading disk.sys in the open sourced Windows-Samples repository. I am *guessing* that disk.sys is given (fed? probed? scanned?) a list of \PhysicalDriveX - where it tries to read the partition table, and for each valid partition, creates the \Volumes{} node(s). Is that right? In the ball park? I compiled in the disk.sys sources to ZFS, and run it.. only to find that nothing really happens. Sure, the "ClassAddDevice = DiskAddDevice" callback is triggered once, but it doesn't seem to be a \PhysicalDriveX that it is given (is it a filter?), so clearly I am guessing wrong as to what disk.sys does. Ignoring the \PhysicalDriveX situation, I try to simply call disk.sys's DiskCreateFdo() to create my own \Volumes{}. But it takes a PhysicalDeviceObject. Does it always have to attach to an existing \PhysicalDriveX node? Can't I just make one up? It currently fails at IoAttachDeviceToDeviceStack() with 0xc0000001. I know this question is a bit vague, and it must be tedious to work with a hardcore Unix guy like myself, but I would appreciate any wisdom you can throw my way :) My hack/slash way to attempt a \Volume{} to appear is here: zfs_vnops_windows_lib.c#L1004 Lund -- Jorgen Lundman | <> Unix Administrator | +81 (0)90-5578-8500 Shibuya-ku, Tokyo | Japan
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 00:34.

Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license