Custom routing of file operations.

NTFSD
1

We currently talk to some external networked hardware by providing the user with a custom UI to access its “file system” (via an internal API). What we’d like to achieve is to integrate the hardware onto a mounted drive and act like regular storage device accessible by explorer and the command line. Essentially making it transparent as to its origins. Namespace extensions would get us the Explorer functionality, but this does not solve the command prompt requirements and overall transparency that we’d like. To do this, I believe we need to go down the device driver route.

I’ve been looked at mini filters, device namespaces, and device drivers, and I’m not 100% sure which route to pursue next, so I thought you guys may be able to help :slight_smile:

This is how I perceive it working:

  • In some way mount the device with the mount manager so to get a drive letter mapping to our device.
  • Intercept any calls to the device.
  • Use kernel/user communication to access the existing (user mode) API to transfer the requested file data from the hardware to shared user/kernel memory, notify back into the kernel driver on completion, which then handles passing the data back to the caller.
  • Do not let this request go any further down the drive stack as it makes no sense to anyone else.

So, basically we are intercepting device operations, routing them back out to a user mode process where the request is acted upon, and the results stored in shard memory. The kernel mode section is then notified and it does its thing to transfer the data back to the caller as required.

Looking at mini filter drivers, I believe we can intercept file access to our mounted device, but can we re-direct the operation via user mode code? Do we have to write a full device driver to get this sort of functionality? It sounds similar to file system redirectors, but also perhaps in the realm of mini filters, or perhaps it’s just not something you can do without some major device driver work.

Thanks for any help/advice/pointers you can give me on this.

Cheers,
Simon.

2

Take a look at redirectors, this is not a good match for a mini-filter
because there is no underlying file system. I have not personally used it,
but you might look at http://www.eldos.com/cbfs/ this does basically what
you are looking for.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> We currently talk to some external networked hardware by providing the
> user with a custom UI to access its “file system” (via an internal API).
> What we’d like to achieve is to integrate the hardware onto a mounted
> drive and act like regular storage device accessible by explorer and the
> command line. Essentially making it transparent as to its origins.
> Namespace extensions would get us the Explorer functionality, but this
> does not solve the command prompt requirements and overall transparency
> that we’d like. To do this, I believe we need to go down the device driver
> route.
>
> I’ve been looked at mini filters, device namespaces, and device drivers,
> and I’m not 100% sure which route to pursue next, so I thought you guys
> may be able to help :slight_smile:
>
> This is how I perceive it working:
>
> - In some way mount the device with the mount manager so to get a drive
> letter mapping to our device.
> - Intercept any calls to the device.
> - Use kernel/user communication to access the existing (user mode) API to
> transfer the requested file data from the hardware to shared user/kernel
> memory, notify back into the kernel driver on completion, which then
> handles passing the data back to the caller.
> - Do not let this request go any further down the drive stack as it makes
> no sense to anyone else.
>
> So, basically we are intercepting device operations, routing them back out
> to a user mode process where the request is acted upon, and the results
> stored in shard memory. The kernel mode section is then notified and it
> does its thing to transfer the data back to the caller as required.
>
> Looking at mini filter drivers, I believe we can intercept file access to
> our mounted device, but can we re-direct the operation via user mode code?
> Do we have to write a full device driver to get this sort of
> functionality? It sounds similar to file system redirectors, but also
> perhaps in the realm of mini filters, or perhaps it’s just not something
> you can do without some major device driver work.
>
> Thanks for any help/advice/pointers you can give me on this.
>
> Cheers,
> Simon.
>

3

I’m kind of lost in the description here… Regarding the statement, “Do not
let this request go any further down the drive stack as it makes no sense to
anyone else.”, well, this is where I lost the OP.

Does this mean you’re/he is looking for a virtual disk type solution?

If I remember correctly, there is a new ram disk sample in the newest WDK…
Perhaps a mini-filter reading/redirecting
to a ram disk based upon certain criteria is what he is looking for?

To mount a device, a recognized file system must be present, so does this
mean that once a mount occurs, he wants data
from the device transferred to a ram disk where it can be manipulated and
changes are never passed back to the hardware?

Something where all user mode interaction is routed through the mini-filter
which redirects to a ram disk?

Matt…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, December 01, 2008 5:45 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Custom routing of file operations.

We currently talk to some external networked hardware by providing the user
with a custom UI to access its “file system” (via an internal API). What
we’d like to achieve is to integrate the hardware onto a mounted drive and
act like regular storage device accessible by explorer and the command line.
Essentially making it transparent as to its origins. Namespace extensions
would get us the Explorer functionality, but this does not solve the command
prompt requirements and overall transparency that we’d like. To do this, I
believe we need to go down the device driver route.

I’ve been looked at mini filters, device namespaces, and device drivers, and
I’m not 100% sure which route to pursue next, so I thought you guys may be
able to help :slight_smile:

This is how I perceive it working:

  • In some way mount the device with the mount manager so to get a drive
    letter mapping to our device.
  • Intercept any calls to the device.
  • Use kernel/user communication to access the existing (user mode) API to
    transfer the requested file data from the hardware to shared user/kernel
    memory, notify back into the kernel driver on completion, which then handles
    passing the data back to the caller.
  • Do not let this request go any further down the drive stack as it makes no
    sense to anyone else.

So, basically we are intercepting device operations, routing them back out
to a user mode process where the request is acted upon, and the results
stored in shard memory. The kernel mode section is then notified and it does
its thing to transfer the data back to the caller as required.

Looking at mini filter drivers, I believe we can intercept file access to
our mounted device, but can we re-direct the operation via user mode code?
Do we have to write a full device driver to get this sort of functionality?
It sounds similar to file system redirectors, but also perhaps in the realm
of mini filters, or perhaps it’s just not something you can do without some
major device driver work.

Thanks for any help/advice/pointers you can give me on this.

Cheers,
Simon.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: matt-martin@tx.rr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

4

Sorry if I wasn’t clear Matt, i’ll try again.

We have an external “black box” device that we communicate with via a predefined API to retrieve information about files held on its internal file system. We currently then use this API to expose the file system to users via a Windows application that looks a bit like Windows Explorer.

Recently we have implemented a namespace extension to make the device more “transparent” to the user, thus integrating it into the main Windows Explorer window, but the ultimate goal is to integrate this external file system into windows in such a way as it is mounted as a drive letter so that it would be usable in explorer, from the command line, and so on - thus pretty much transparent to the end user. The caveat here is that we have to communicate with the external device using its (user mode) API.

I’ve been looking in what options we have to achieve this. Could a minifilter do this? Do we need to develop our own filesystem driver etc.? I thought I’d post here to see if any of you might be able to steer me in the right direction.

I shall take a closer look at the ramdisk sample Matt …

Hope this makes things clearer.

Simon.

5

The ramdisk will only work on block level so since you say it is a file
system this will not work. You basically have four choices:

  1. Write your own file system and recognizer from scratch (using
    FastFat as a guide)
  2. Write a redirector file system (this has some restrictions) using
    the Rdr api’s in the WDK
  3. Get the OSR file system development kit
    http://www.osr.com/toolkits_fsdk.shtml this is outstanding but some people
    consider it pricey
  4. Investigate the Eldos Callback File system
    http://www.eldos.com/cbfs/ which does what your original post described,
    namely redirect file operations to user space. As I said in the earlier
    post, I have not tried this.

Do not try to mess with a filter, you do not have an underlying Windows file
system to filter. Do not mess with disk level stuff, since you describe
your environment as an external file system.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> Sorry if I wasn’t clear Matt, i’ll try again.
>
> We have an external “black box” device that we communicate with via a
> predefined API to retrieve information about files held on its internal
> file system. We currently then use this API to expose the file system to
> users via a Windows application that looks a bit like Windows Explorer.
>
> Recently we have implemented a namespace extension to make the device more
> “transparent” to the user, thus integrating it into the main Windows
> Explorer window, but the ultimate goal is to integrate this external file
> system into windows in such a way as it is mounted as a drive letter so
> that it would be usable in explorer, from the command line, and so on -
> thus pretty much transparent to the end user. The caveat here is that we
> have to communicate with the external device using its (user mode) API.
>
> I’ve been looking in what options we have to achieve this. Could a
> minifilter do this? Do we need to develop our own filesystem driver etc.?
> I thought I’d post here to see if any of you might be able to steer me in
> the right direction.
>
> I shall take a closer look at the ramdisk sample Matt …
>
> Hope this makes things clearer.
>
> Simon.
>

6

BTW, the FSDK can also redirect file operations to user mode.

Mark Cariddi
OSR

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Monday, December 01, 2008 10:24 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Custom routing of file operations.

The ramdisk will only work on block level so since you say it is a file
system this will not work. You basically have four choices:

  1. Write your own file system and recognizer from scratch (using
    FastFat as a guide)
  2. Write a redirector file system (this has some restrictions)
    using
    the Rdr api’s in the WDK
  3. Get the OSR file system development kit
    http://www.osr.com/toolkits_fsdk.shtml this is outstanding but some
    people
    consider it pricey
  4. Investigate the Eldos Callback File system
    http://www.eldos.com/cbfs/ which does what your original post
    described,
    namely redirect file operations to user space. As I said in the earlier

post, I have not tried this.

Do not try to mess with a filter, you do not have an underlying Windows
file
system to filter. Do not mess with disk level stuff, since you describe

your environment as an external file system.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

wrote in message news:xxxxx@ntfsd…
> Sorry if I wasn’t clear Matt, i’ll try again.
>
> We have an external “black box” device that we communicate with via a
> predefined API to retrieve information about files held on its
internal
> file system. We currently then use this API to expose the file system
to
> users via a Windows application that looks a bit like Windows
Explorer.
>
> Recently we have implemented a namespace extension to make the device
more
> “transparent” to the user, thus integrating it into the main Windows
> Explorer window, but the ultimate goal is to integrate this external
file
> system into windows in such a way as it is mounted as a drive letter
so
> that it would be usable in explorer, from the command line, and so on
-
> thus pretty much transparent to the end user. The caveat here is that
we
> have to communicate with the external device using its (user mode)
API.
>
> I’ve been looking in what options we have to achieve this. Could a
> minifilter do this? Do we need to develop our own filesystem driver
etc.?
> I thought I’d post here to see if any of you might be able to steer me
in
> the right direction.
>
> I shall take a closer look at the ramdisk sample Matt …
>
> Hope this makes things clearer.
>
> Simon.
>

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@gmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

If you want the ‘drive’ you are exposing to look like a local hard disk,
not a network share, then there are 2 main components you will need.

  1. A pseudo-device integrated with PnP and MntMgr to get your file
    system loaded. You can use something like the Toaster bus sample to
    enumerate PDOs that will expose a GenDisk ID so the system will build up
    everything. You then have some custom IOCtl, or other method, to ‘know’
    it is your device so in the FSD mount processing you will correctly
    mount the device. The problem with the RamDisk sample is that it is not
    correctly integrated with the MntMgr and thus there are limitations and
    problems you will hit down the road.

  2. Implement the file system that will process the mount requests and
    then redirect ‘everything’ off to where it will be processed, nothing
    will go ‘down the stack’ to the PDO enumerated in step 1). Of course,
    not everything will be sent away, you will need to implement a big chunk
    of the code in the file system to handle things like MM and CM
    integration, locking, and other.

As Mark C. indicated, the OSR FSDK can ease the implementation of step 2
so you would only need to implement the lower edge which passes things
off to the hardware or remote device.

We have implemented several of these systems for various clients and
expect about 3 months for 1) and 4-18 months, depending on which path
you take, for 2).

Pete

xxxxx@gmail.com wrote:

We currently talk to some external networked hardware by providing the user with a custom UI to access its “file system” (via an internal API). What we’d like to achieve is to integrate the hardware onto a mounted drive and act like regular storage device accessible by explorer and the command line. Essentially making it transparent as to its origins. Namespace extensions would get us the Explorer functionality, but this does not solve the command prompt requirements and overall transparency that we’d like. To do this, I believe we need to go down the device driver route.

I’ve been looked at mini filters, device namespaces, and device drivers, and I’m not 100% sure which route to pursue next, so I thought you guys may be able to help :slight_smile:

This is how I perceive it working:

  • In some way mount the device with the mount manager so to get a drive letter mapping to our device.
  • Intercept any calls to the device.
  • Use kernel/user communication to access the existing (user mode) API to transfer the requested file data from the hardware to shared user/kernel memory, notify back into the kernel driver on completion, which then handles passing the data back to the caller.
  • Do not let this request go any further down the drive stack as it makes no sense to anyone else.

So, basically we are intercepting device operations, routing them back out to a user mode process where the request is acted upon, and the results stored in shard memory. The kernel mode section is then notified and it does its thing to transfer the data back to the caller as required.

Looking at mini filter drivers, I believe we can intercept file access to our mounted device, but can we re-direct the operation via user mode code? Do we have to write a full device driver to get this sort of functionality? It sounds similar to file system redirectors, but also perhaps in the realm of mini filters, or perhaps it’s just not something you can do without some major device driver work.

Thanks for any help/advice/pointers you can give me on this.

Cheers,
Simon.

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

8

“The ramdisk will only work on block level so since you say it is a file
system this will not work.”

If his device uses a Fat file system, then something like this would work
right? Given all USB devices I’ve seen myself (thumb drives, camera’s, my
phone, etc.) use FAT, a block copy would work right, then again USB hasn’t
a lot to do with this question.

Just wondering how far off I am in theory.

Matt

9

Matt,

That assumes that he has a block level interface, not a FAT interface
since the file system resides above the disk. The OP describes things a
set of user mode API’s for file operations so I don’t think this will work
at all.

–
Don Burn (MVP, Windows DDK)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Matt” wrote in message news:xxxxx@ntfsd…
>
> “The ramdisk will only work on block level so since you say it is a file
> system this will not work.”
>
> If his device uses a Fat file system, then something like this would work
> right? Given all USB devices I’ve seen myself (thumb drives, camera’s, my
> phone, etc.) use FAT, a block copy would work right, then again USB hasn’t
> a lot to do with this question.
>
> Just wondering how far off I am in theory.
>
> Matt
>
>
>
>

10

From the OP’s description I am guessing they have their own format for
the file system data. Thus as the IRPs are processed by the file system,
and not passed through to the underlying device, they would bundle the
request up to retrieve/set the correct information in the remote device
and complete it within the file system.

That said, if they do have a native file system format on their device
then simply exposing a PDO that would access the data at that level
would be completely reasonable.

Pete

Matt wrote:

“The ramdisk will only work on block level so since you say it is a file
system this will not work.”

If his device uses a Fat file system, then something like this would work
right? Given all USB devices I’ve seen myself (thumb drives, camera’s, my
phone, etc.) use FAT, a block copy would work right, then again USB hasn’t
a lot to do with this question.

Just wondering how far off I am in theory.

Matt

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: xxxxx@kerneldrivers.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

11

> We currently talk to some external networked hardware by providing the user with a custom UI to

access its “file system” (via an internal API). What we’d like to achieve is to integrate the hardware
onto a mounted drive and act like regular storage device accessible by explorer and the command

What is the protocol used by the device? block read/write, or some file-related?

If first - then the job is more or less simple, at least on 2003 and later (virtual STORPORT miniport).

If second - then sorry, you will need a full filesystem driver, which is a very major effort.

Probably it will be much easier to enhance the device to speak SMB protocol and be an SMB server.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

12

>usable in explorer, from the command line, and so on - thus pretty much transparent to the end user.

  1. ElDos’s product
    OR
  2. full blown filesystem, namely RDBSS’s mini-redir
    OR
  3. enhance the device to speak SMB protocol

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

13

Maxim S. Shatskih wrote:

> We currently talk to some external networked hardware by providing the user with a custom UI to
> access its “file system” (via an internal API). What we’d like to achieve is to integrate the hardware
> onto a mounted drive and act like regular storage device accessible by explorer and the command

What is the protocol used by the device? block read/write, or some file-related?

If first - then the job is more or less simple, at least on 2003 and later (virtual STORPORT miniport).

If second - then sorry, you will need a full filesystem driver, which is a very major effort.

Probably it will be much easier to enhance the device to speak SMB protocol and be an SMB server.

Unless performance is of concern, going through the Windows client is
verging on tortuous …

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

14

> 1) A pseudo-device integrated with PnP and MntMgr to get your file

system loaded. You can use something like the Toaster bus sample to
enumerate PDOs that will expose a GenDisk ID

…or better expose the storage port’s upper edge - namely IRP_MJ_SCSI and a couple of IOCTLs.

“GenDisk” should still be the PnP ID of the disk devnode.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

15

> Unless performance is of concern, going through the Windows client is

verging on tortuous …

Windows SMB client has only some very minor performance issues (compared to FreeBSD’s “smbfs”), and I can hardly expect the custom 3rd party redir to be faster.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

16

Maxim S. Shatskih wrote:

> 1) A pseudo-device integrated with PnP and MntMgr to get your file
> system loaded. You can use something like the Toaster bus sample to
> enumerate PDOs that will expose a GenDisk ID

…or better expose the storage port’s upper edge - namely IRP_MJ_SCSI and a couple of IOCTLs.

Definitely you would need to handle the IRP_MJ_SCSI requests since
disk.sys would be sending the IO requests down to you in this format.
You can also use this is the file system recognition interface where the
file system just sends a read of block zero and you return some well
known identifier from the PDO.

“GenDisk” should still be the PnP ID of the disk devnode.

Right, it eliminates the need to implement the entire lower storage stack.

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

17

Maxim S. Shatskih wrote:

> Unless performance is of concern, going through the Windows client is
> verging on tortuous …

Windows SMB client has only some very minor performance issues (compared to FreeBSD’s “smbfs”), and I can hardly expect the custom 3rd party redir to be faster.

I beg to differ. In all my ‘remote’ file system implementations for
clients, the primary impetus for a full file system was to by-pass the
Windows client due to scalability and performance concerns. There are
bottle necks in the Vista and previous implementations when dealing with
aggregate throughput from multiple applications as well as scalability
when accessing large clustered data stores containing millions of nodes.

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

18

> Definitely you would need to handle the IRP_MJ_SCSI requests since

disk.sys would be sending the IO requests down to you in this format.

OK, so, we are speaking about the same thing - full storage port namely.

Right, it eliminates the need to implement the entire lower storage stack.

Yes, your full port will be the lowest driver in the stack.

Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

19

> I beg to differ. In all my ‘remote’ file system implementations for

clients, the primary impetus for a full file system was to by-pass the
Windows client due to scalability and performance concerns.

Are you doing this with SMB protocol or some protocol of your own?

Probably NFS is faster (if they solved the caching issues in it at last).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

20

Maxim S. Shatskih wrote:

> I beg to differ. In all my ‘remote’ file system implementations for
> clients, the primary impetus for a full file system was to by-pass the
> Windows client due to scalability and performance concerns.

Are you doing this with SMB protocol or some protocol of your own?

They have all been proprietary protocols.

Probably NFS is faster (if they solved the caching issues in it at last).

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295