Prev: Can't link to a driver support DLL from MFC application
Next: Replacing USBSTOR.sys
From: TestJ on 11 Apr 2010 23:40
Hello all,

I have a bit of a problem. I have some code where a process gets some win32
DOS path and sends it down to a driver so that the driver could add it to its
work queue. Then, the user-level process opens the file using OpenFile which
then creates an IRP for the driver. When the driver gets the IRP, it checks
its work queue to see if it should perform work on it. This is how the
process and the driver communicate.

The problem I am having though is trying to find a canonical form that both
the user-level process and the driver understand. The user-level process
only understands Dos paths e.g. c:\blah\blah\myFile.doc whereas the kernel
driver gets the IRP which has the NT path to the file e.g.
\Device\Volume\blah\\blah\myFile.doc. Also, what makes this problem more
difficult, is that the user can request work on a network share or a network
mapped drive so the user-level process can send down
\\192.168.1.1\share\blah\lbah.doc or z:\blah\blah.doc, and somehow the driver
needs to know which file that the user-level process is referring to.

does anyone have any creative ways to determine this?

Thanks!
From: Pavel A. on 12 Apr 2010 03:56
Finding a canonical path can be dificult, especially with DFS.
Why these files must be processed in kernel mode rather
than a service? In case of network files, how you ensure that
the driver has access to the network share on behalf
of the user?

Regards,
-- pa

"TestJ" <TestJ(a)discussions.microsoft.com> wrote in message
news:2B1153C4-0957-469A-ACF4-0A34765BDC4E(a)microsoft.com...
> Hello all,
>
> I have a bit of a problem. I have some code where a process gets some
> win32
> DOS path and sends it down to a driver so that the driver could add it to
> its
> work queue. Then, the user-level process opens the file using OpenFile
> which
> then creates an IRP for the driver. When the driver gets the IRP, it
> checks
> its work queue to see if it should perform work on it. This is how the
> process and the driver communicate.
>
> The problem I am having though is trying to find a canonical form that
> both
> the user-level process and the driver understand. The user-level process
> only understands Dos paths e.g. c:\blah\blah\myFile.doc whereas the kernel
> driver gets the IRP which has the NT path to the file e.g.
> \Device\Volume\blah\\blah\myFile.doc. Also, what makes this problem more
> difficult, is that the user can request work on a network share or a
> network
> mapped drive so the user-level process can send down
> \\192.168.1.1\share\blah\lbah.doc or z:\blah\blah.doc, and somehow the
> driver
> needs to know which file that the user-level process is referring to.
>
> does anyone have any creative ways to determine this?
>
> Thanks!

 | 
Pages: 1
Prev: Can't link to a driver support DLL from MFC application
Next: Replacing USBSTOR.sys